webpack-dev-server EUVD-2026-108108

Exploitation requires a devServer.proxy entry explicitly configured with ws:true (WebSocket forwarding); without that proxy/ws configuration the gap does not exist, so default configurations without proxied WebSockets are not affected. It further requires that a developer, while the dev server is running, visit an attacker-controlled web page (UI:R) that scripts a cross-origin WebSocket - the upgrade bypasses the middleware chain and therefore the allowedHosts/Host/Origin checks that already refuse the same route over plain HTTP. Loopback binding does NOT mitigate it because the browser originates the connection. Limiting factors: non-default proxy ws:true configuration, required developer interaction with a malicious page, and the dev-time-only nature of the server. The vendor states omitting ws:true from proxy entries that do not need it and scoping proxy context to specific paths as workarounds, with upgrading to 5.2.7 or 6.1.0 as the fix.

The CVSS 3.1 base score of 8.2 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N) is driven largely by the scope change (S:C) and high confidentiality impact: an unauthenticated, network-reachable attacker needs only low complexity, but does require user interaction (UI:R) because a developer must visit a malicious page while the dev server is running. Two signals are missing from the input: no EPSS probability is provided and the vulnerability is not listed in CISA KEV, so there is no confirmed active exploitation. No verified exploit code is present either - the only references are the vendor GHSA advisory and the OpenJSF CNA page, not a PoC. The vuln.today decision label is 'this_week', indicating a prompt but non-emergency priority, which is consistent with the KEV/EPSS picture. The practical risk is materially constrained by two factors the raw score understates: exploitation only works when a proxy entry is explicitly configured with ws:true (a non-default setting), and it requires the developer to be socially engineered into loading attacker-controlled content. This is a genuine development-environment supply-chain/SSRF-style exposure worth patching this week, not a mass-exploitable internet-facing RCE.

A developer runs webpack-dev-server with a devServer.proxy entry configured with ws:true and, while that server is listening (even on loopback), visits a malicious web page in a browser. Attacker JavaScript on that page opens a cross-origin WebSocket to the dev server, which forwards the upgrade to the proxied backend without Host/Origin validation, letting the page read from and write to that backend. No public exploit is identified at time of analysis.