Executive brief
webpack is a popular JavaScript bundler that developers use during the build process. When the experimental buildHttp feature is enabled, it has a security flaw where it doesn't properly verify allow-list restrictions when following HTTP redirects. An attacker with control over an allowed domain can redirect the build to fetch JavaScript from internal servers or external malicious sources, potentially allowing unauthorized access to internal systems (SSRF) or injecting malicious code into the final bundle. The fetched content is also cached, making the attack persistent.
Technical details
The vulnerability exists in webpack's HTTP(S) resolver when experiments.buildHttp is enabled. The allowedUris validation is performed during the initial getInfo() call but is not re-checked when the HTTP resolver follows Location headers in 30x redirect responses. An attacker controlling an allowed host can issue a 302 redirect to any URL—either an internal-only service (SSRF) or attacker-controlled external site. The redirected content is treated as legitimate module source, bundled into the output, and persisted in the buildHttp cache. This enables both server-side request forgery from the build machine and code injection into the final bundle. Exploitation requires buildHttp to be explicitly enabled and the attacker to control (or find an open redirect on) an allowed domain. The vulnerability affects webpack versions ≥5.49.0 <5.104.0; version 5.104.0 patches the issue by re-validating allowedUris after redirects.
Affected products
- webpack webpack >=5.49.0, <5.104.0
Timeline
- 2026-02-05: disclosed
- 2026-02-05: patched: Version 5.104.0 released with fix