CVE-2026-6402

What it actually does

webpack-dev-server versions up to and including 5.2.3 can expose bundled application source code across origins when the development server is served over a non-trustworthy origin, such as plain HTTP. The prior protection depended on browser Fetch Metadata headers such as Sec-Fetch-Mode and Sec-Fetch-Site, but browsers may omit those headers for non-trustworthy origins. As a result, a malicious web page can cause the developer’s browser to load the dev-server bundle as a script and read source content that should have been restricted to the same origin. The issue affects confidentiality only; it does not directly allow code execution, data modification, or service disruption.

Why it matters to the business

The main business risk is leakage of proprietary application source code from developer workstations or development environments. Exposed source can reveal business logic, internal API routes, feature flags, credentials accidentally committed into client-side code, security assumptions, or implementation details that make later attacks easier. Exploitation requires user interaction: a developer must visit an attacker-controlled page while running an affected webpack-dev-server instance over HTTP at a discoverable host and port. The CVSS score is medium and EPSS is low, and it is not listed in CISA KEV, but organizations with many JavaScript projects or distributed developer teams should still treat remediation as important because source disclosure can materially increase downstream security risk.

How an attack unfolds

An attacker first prepares a malicious website designed to probe common webpack-dev-server locations, such as localhost or private-network hostnames on typical development ports. The attacker then convinces a developer to visit that site while the developer has an affected webpack-dev-server instance running over plain HTTP. Because the dev server is on a non-potentially trustworthy origin, the browser may omit Fetch Metadata headers that the previous protection relied on. The malicious page can load the dev-server bundle as a script from the guessed host and port and recover the served application source or bundled code across origins. The attacker then reviews the recovered source for secrets, internal endpoints, authentication assumptions, vulnerable code paths, or intellectual property. Chromium-based browsers from Chrome 142 onward reduce exposure through local network access restrictions, but affected server versions should still be upgraded because protection should not rely only on client browser behavior.

How to fix it

Upgrade webpack-dev-server to version 5.2.4 or later. Version 5.2.4 adds Cross-Origin-Resource-Policy: same-origin to responses, preventing this class of cross-origin source exposure. Because no per-package fixed version list was provided beyond the advisory text, security teams should verify package manifests and lockfiles directly for webpack-dev-server versions and ensure all dependency resolution paths select 5.2.4 or newer. As additional defense-in-depth, avoid exposing development servers on shared networks, bind dev servers to localhost where possible, prefer trusted HTTPS origins for development workflows, use randomized or non-default ports where practical, and avoid storing secrets in frontend source code. Browser-side mitigations in newer Chromium versions should not be considered a complete fix.

How to confirm the fix worked

Confirm that all projects using webpack-dev-server resolve to version 5.2.4 or later by checking package manifests and lockfiles, for example package.json, package-lock.json, yarn.lock, or pnpm-lock.yaml. Run dependency audit tooling such as npm audit, yarn npm audit, pnpm audit, SCA scanners, or repository-wide dependency inventory queries to identify any remaining versions up to and including 5.2.3. For running development servers, send a test HTTP request to served assets and verify that responses include the header Cross-Origin-Resource-Policy: same-origin. Also confirm that development servers are not reachable from untrusted networks and are not bound broadly unless required.

Typical attack path

1. Identify that the target organization likely uses webpack-dev-server for JavaScript development.
2. Host a malicious web page containing logic to request common webpack-dev-server URLs and ports over HTTP.
3. Lure a developer into visiting the malicious site while a local or development webpack-dev-server instance is running.
4. Use the developer’s browser to load the dev-server bundle cross-origin as a script from a guessable host and port.
5. Read or infer the exposed bundled source code from the loaded script content.
6. Analyze the recovered source for secrets, internal service details, business logic, or vulnerabilities useful for follow-on attacks.

How to detect it

To determine whether exploitation may already have occurred, review developer workstation browser history, proxy logs, DNS logs, endpoint telemetry, and local web server access logs for suspicious web pages visited while webpack-dev-server was running. Look for requests to common webpack-dev-server ports, especially 8080, 3000, 3001, 5173, or 9000, that include unusual cross-origin Referer or Origin values pointing to unrelated external websites. Examine HTTP access logs for JavaScript bundle or source map requests from a browser session immediately after navigation to an unknown site. Endpoint telemetry may show development server processes such as node serving webpack-dev-server during the same time window as outbound browsing to untrusted domains. Since this vulnerability primarily leaks source through the developer’s browser, server-side artifacts may be limited or absent unless dev-server access logging, endpoint web proxy logging, or browser forensic artifacts are available.

• webpack-dev-server
• Cross-Origin-Resource-Policy: same-origin
• Sec-Fetch-Mode
• Sec-Fetch-Site
• GET /main.js
• GET /bundle.js
• GET /app.js
• GET /static/js/
• GET /webpack-dev-server
• GET /sockjs-node
• GET /ws
• GET /*.js.map
• Origin: http://
• Referer: http://
• localhost:8080
• 127.0.0.1:8080
• localhost:3000
• 127.0.0.1:3000
• localhost:3001
• 127.0.0.1:3001
• localhost:9000
• 127.0.0.1:9000
• node_modules/webpack-dev-server
• package-lock.json
• yarn.lock
• pnpm-lock.yaml

What your security team should do

• Prioritize upgrading webpack-dev-server to 5.2.4 or later across all JavaScript development repositories and templates.
• Search package manifests and lockfiles for webpack-dev-server versions up to and including 5.2.3, including transitive or workspace-level dependency resolution.
• Update developer workstation guidance to run dev servers on localhost only and avoid exposing them over plain HTTP to shared or untrusted networks.
• Add CI or dependency-management rules that block newly introduced vulnerable webpack-dev-server versions.
• Review frontend bundles and repositories for hardcoded secrets or sensitive internal implementation details that could be damaging if source is exposed.
• Educate developers to avoid visiting untrusted websites while local development services are running, especially services exposed on predictable ports.
• If suspicious activity is identified, rotate any credentials or tokens found in client-side source and review source-exposed internal endpoints for abuse.