Where
-Infinity
0
Severity
8.2
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N

webpack-dev-server is a development server that provides live reloading for webpack projects. In versions before 5.2.7 and in version 6.0.0, when a proxy entry is configured to forward WebSockets, the server forwards non-HMR WebSocket upgrade requests to the proxy target without validating the Host or Origin headers, so the allowedHosts protection does not apply to those proxied upgrades. A malicious web page visited by a developer can open a cross-origin WebSocket through the dev server and read from and write to the proxied backend, even when the server is bound to loopback. The issue is fixed in webpack-dev-server 5.2.7 and 6.1.0, where proxied WebSocket upgrades pass the same Host and Origin validation as the HMR WebSocket, and users should upgrade to one of those versions or later. As a workaround, omit WebSocket forwarding from proxy entries that do not need it and scope the proxy to specific paths.

First published (updated )
Severity
5.3
EPSS
0.23%
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

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.

1 / 3
Source: GitHub
First published (updated )
Severity
6.5
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N

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

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203