webpack-dev-server CVE-2026-6402

Exploitation requires all of the following concrete conditions to be met: (1) webpack-dev-server versions 5.2.3 or earlier must be running and accessible over HTTP (not HTTPS). (2) The dev server must be accessible from the attacker's origin, typically because it is bound to a network interface (not localhost-only) or port-scanned/guessed by the attacker. (3) A developer using the vulnerable server must visit a website controlled by or compromised by the attacker while the dev server is running. (4) The browser must not enforce local network access restrictions (e.g., Chromium 142+ excludes this). The description explicitly identifies the root condition as 'non-potentially trustworthy origin such as plain HTTP' - the Sec-Fetch-* headers are omitted for HTTP origins, enabling the cross-origin read. Limiting factors: authentication is not required (PR:N), but user interaction is mandatory (a developer must click a link or navigate to the attacker's site), hence AC:H. The attack fails if the dev server is localhost-only, uses HTTPS, or if the developer does not visit an attacker-controlled site. Non-Chromium browsers (Firefox, Safari, older Chrome) are affected; modern Chromium browsers are protected by local network access restrictions independent of this fix.

This vulnerability presents moderate real-world risk with significant context-dependent factors. CVSS score of 5.3 reflects the threat model: Network vector (AV:N) and unauthenticated (PR:N) attack, but High complexity (AC:H) due to the mandatory user interaction requirement - a developer must visit an attacker-controlled website while running an unpatched dev server. The confidentiality impact is High (C:H) because full source code exposure can leak intellectual property, secrets, and architecture. Exploitation likelihood is suppressed by several practical factors: the attacker must guess the dev server's host and port (typically localhost:8080 or 3000, making enumeration feasible but not certain), the target must be a developer (not an end user), and the developer must visit a malicious site during their dev session. No EPSS score or KEV status provided, suggesting no confirmed active exploitation in the wild at time of advisory. However, the attack is straightforward to execute once conditions are met, and source code exposure is a high-value target. Organizations with developers regularly testing on HTTP (rather than HTTPS or localhost-only) face elevated risk. The Chromium exception (Chrome 142+) reduces risk for modern Chrome users via local network access restrictions, but other browsers and older Chrome versions remain vulnerable. Defense is simple (upgrade), making patch adoption a key risk factor.

A developer clones a project repository and runs 'npm install && npm start', which launches webpack-dev-server on http://localhost:8080 (or http://192.168.1.100:8080 if explicitly configured for network access). The developer then opens a GitHub issue or pulls a link from Slack pointing to an attacker's website, malicious-ads.example.com. The attacker's page includes hidden JavaScript: fetch('http://localhost:8080/main.bundle.js').then(r => r.text()).then(code => /* exfiltrate code */). Alternatively, the page uses a <script> tag: <script src='http://localhost:8080/main.bundle.js'></script>, and injected code inspects window.myApp or other globals to extract the bundled code. The bundled source code (containing API keys, business logic, and architecture) is sent to the attacker's server. No special tools or privileges are required; a simple HTML page and JavaScript suffice.