CVE-2026-112085: webpack-dev-server vulnerable to cross-origin WebSocket access via proxied upgrades
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
webpack-dev-serverto a version that resolves this vulnerability.Fixed in 5.2.7 - Upgrade
Upgrade
webpack-dev-serverto a version that resolves this vulnerability.Fixed in 6.1.0 - Configuration
Omit WebSocket forwarding from proxy entries that do not need it.
webpack-dev-server proxy entries WebSocket forwarding = disabled for proxy entries that do not require it - Configuration
Scope the proxy to the specific paths that require forwarding.
webpack-dev-server proxy proxy scope = specific paths only
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Affected deployments are webpack-dev-server instances before 5.2.7 and version 6.0.0 that have a proxy entry configured to forward WebSocket connections. Binding the development server only to loopback does not prevent exploitation.
What does an attacker need to exploit it?
An attacker needs a developer using the affected dev server to visit a malicious web page. That page can initiate a cross-origin WebSocket upgrade through the dev server to the proxied backend, without needing prior privileges.
What can be done if an upgrade cannot happen immediately?
Remove WebSocket forwarding from proxy entries where it is not required. For proxies that must remain, limit them to specific paths.
How is this addressed in fixed releases?
Version 5.2.7 and version 6.1.0 apply the same Host and Origin validation to proxied WebSocket upgrades that is used for the HMR WebSocket. Upgrade to one of those versions or a later release.