CVE-2026-9595

What it actually does

webpack-dev-server can incorrectly route its own hot module replacement (HMR) WebSocket traffic through a user-configured proxy when the proxy context is overly broad, such as `/`, and `ws: true` is enabled. In that configuration, the dev server forwards WebSocket upgrade requests intended for its internal HMR endpoint to the configured proxy target, which can expose browser-supplied headers such as `Cookie` and `Origin` to that backend. This also bypasses webpack-dev-server’s normal Host/Origin validation for the HMR WebSocket path and can break HMR functionality because both the dev server and proxy target may write to the same socket.

Why it matters to the business

The practical risk is highest for development environments that are reachable beyond a trusted local network or that proxy to backends outside the developer’s direct control. Sensitive browser cookies or origin information can be unintentionally disclosed to the configured proxy target, and developer workflows may be disrupted by broken hot reload behavior. Although this is not currently listed in CISA KEV, has no known public exploit maturity, and has a low EPSS score, organizations with widely shared development servers or internet-exposed dev tooling should still prioritize cleanup because misconfigured dev infrastructure often escapes normal production controls.

How an attack unfolds

An attacker first identifies a reachable webpack-dev-server instance using a vulnerable version and a broad proxy rule that matches `/` with WebSocket forwarding enabled. The attacker then initiates or induces WebSocket traffic to the dev server’s HMR endpoint. Because the proxy configuration matches the HMR WebSocket path, webpack-dev-server forwards the upgrade request to the configured proxy target instead of handling it internally. The forwarded request can include browser cookies and the Origin header, allowing the proxy target or anyone with access to its logs or traffic to observe information that should have remained within the dev server context. The same misrouting can also corrupt the HMR socket, causing hot reload failures or development-server instability.

How to fix it

Upgrade webpack-dev-server to version 5.2.5 or later wherever it is used. If immediate upgrade is not possible, narrow proxy contexts so they only match intended application paths instead of `/`, and remove `ws: true` from proxy entries unless WebSocket forwarding is explicitly required. Avoid exposing webpack-dev-server to untrusted networks; bind development servers to localhost where possible, place them behind authentication if remote access is required, and ensure development cookies are not shared with sensitive production services.

How to confirm the fix worked

Confirm dependency resolution shows webpack-dev-server version 5.2.5 or later, including transitive copies in lockfiles. Review webpack configuration files for proxy entries with broad contexts such as `/`, `/**`, or catch-all functions combined with `ws: true`. Start the dev server and verify HMR WebSocket traffic is handled by webpack-dev-server rather than forwarded to the application proxy target. Check backend/proxy target access logs during a dev-server session to ensure requests to HMR WebSocket paths are not appearing there with browser cookies or Origin headers.

Typical attack path

1. Discover a webpack-dev-server instance exposed on the network, commonly on development ports such as 8080, 3000, 5173, or similar.
2. Confirm the server is using a vulnerable webpack-dev-server release prior to 5.2.5 or infer exposure from behavior and headers.
3. Identify that the dev server has a broad proxy context such as `/` and WebSocket proxying enabled with `ws: true`.
4. Send or trigger an HMR WebSocket connection to the dev server.
5. The dev server incorrectly proxies the HMR WebSocket request to the configured backend target.
6. Capture or review forwarded headers such as `Cookie` and `Origin` at the proxy target or in intermediary logs.
7. Optionally cause HMR malfunction or socket errors because both HMR handling and proxy forwarding interact with the same WebSocket connection.

How to detect it

Look for evidence that HMR WebSocket traffic was forwarded to an application backend or proxy target rather than being handled locally by webpack-dev-server. Useful sources include webpack-dev-server logs, application backend access logs, reverse-proxy logs, WebSocket gateway logs, package lockfiles, container images, and webpack configuration files. Search backend logs for WebSocket upgrade requests to HMR-related paths such as `/ws`, `/sockjs-node`, or paths containing `webpack`, especially when the same request includes `Cookie`, `Origin`, `Upgrade: websocket`, or `Connection: Upgrade` headers. Also review error logs for failed or corrupted HMR WebSocket sessions, repeated socket write errors, or unexpected proxying of development-only endpoints. There are no known threat actors or public exploitation campaigns reported for this issue, so detection should focus on exposure and suspicious forwarding artifacts rather than a fixed attacker fingerprint.

• webpack-dev-server
• webpack-dev-server@5.2.4
• webpack-dev-server@5.2.3
• webpack-dev-server@5.2.2
• webpack-dev-server@5.2.1
• webpack-dev-server@5.2.0
• ws: true
• context: '/'
• context: "/"
• proxy: { '/':
• proxy: { "/":
• Upgrade: websocket
• Connection: Upgrade
• /ws
• /sockjs-node
• webpack/hot
• __webpack_hmr

What your security team should do

• Inventory repositories and development images that include webpack-dev-server and prioritize upgrades to 5.2.5 or later.
• Search webpack configuration for broad proxy rules using `/` together with `ws: true`; remediate these even after upgrading as a defense-in-depth measure.
• Restrict webpack-dev-server exposure to localhost or trusted development networks only.
• Review backend and reverse-proxy logs for unexpected HMR WebSocket paths and forwarded Cookie or Origin headers.
• Ensure development cookies are scoped narrowly and do not carry production privileges.
• Add dependency policy checks so vulnerable webpack-dev-server versions fail builds or dependency review.
• Document approved proxy patterns for development servers, including path-scoped contexts and explicit justification for WebSocket proxying.