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.2.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.
Impact
When webpack-dev-server is running on a non-HTTPS origin (the default), cross-origin requests from malicious websites can load the dev server's JavaScript bundles via <script> tags. The fix introduced in v5.2.1 (CVE-2025-30359) relied on Sec-Fetch-Mode and Sec-Fetch-Site request headers to block these requests, but browsers only send these headers for potentially trustworthy origins. Over plain HTTP, the headers are absent and the check is bypassed.
An attacker who knows the dev server's host, port, and output path can exfiltrate all module source code by intercepting the webpack runtime's module registration.
This does not affect Chrome 142+ (and other Chromium-based browsers) due to local network access restrictions.
Patches
Patched in webpack-dev-server >= 5.2.4 by setting Cross-Origin-Resource-Policy: same-origin on responses.
Workarounds
Run the dev server with HTTPS enabled (--https or server.type: 'https' in config).
Resources
- GHSA-4v9v-hfq4-rm2v (CVE-2025-30359) - original vulnerability - GHSA-9jgg-88mc-972h (CVE-2025-30360) - prior bypass