CVE-2025-68458

What it actually does

Webpack versions 5.49.0 through 5.104.0 can incorrectly enforce the allowedUris policy when experiments.buildHttp is enabled. The vulnerable HTTP(S) resolver may validate a URL using a raw string prefix comparison before URL parsing, allowing a crafted URL containing userinfo syntax such as username:password@host to appear to match an allowed prefix while the actual request is made to a different authority. This can cause build-time server-side request forgery from the build machine and can also cause remote, untrusted HTTP responses to be treated as module source and bundled into the application.

Why it matters to the business

The primary risk is compromise of the software build process rather than direct runtime compromise. If an attacker can influence webpack configuration, imports, dependencies, or source submitted to a build pipeline, they may be able to make build infrastructure contact internal-only services, cloud metadata endpoints, or attacker-controlled hosts, potentially exposing sensitive data or injecting unexpected code into generated artifacts. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it should still be prioritized for teams that use webpack buildHttp with network access from CI/CD or developer build systems.

How an attack unfolds

An attacker first needs a path to influence a webpack build that has experiments.buildHttp enabled and uses allowedUris to restrict remote module fetching. This influence could come from a malicious dependency, a submitted code change, a poisoned package, or any workflow where untrusted source or configuration is built. The attacker supplies an HTTP(S) module URL crafted with userinfo syntax so that the beginning of the raw string appears to match an allowed URI, while the parsed URL authority resolves to another host. Webpack’s vulnerable resolver allows the string through the policy check, then the network stack sends the request to the attacker-chosen host. If that host is internal to the build environment, the attacker may trigger SSRF-style access to internal endpoints; if the response is controlled by the attacker, webpack may incorporate that response as module source into the bundle.

How to fix it

Upgrade webpack to version 5.104.1 or later. For source builds from the webpack Git repository, include the fix commit 24e3c2d2c9f8c6d60810302b2ea70ed86e2863dc or a later commit. If immediate upgrade is not possible, disable experiments.buildHttp, remove or tightly restrict remote HTTP(S) imports, and avoid building untrusted source with network access. Enforce outbound egress controls on CI/CD and developer build systems, especially blocking access to cloud metadata addresses, loopback, RFC1918 private ranges, link-local ranges, and internal administrative services unless explicitly required. Review allowedUris configuration and ensure URL authorization is based on parsed scheme, hostname, port, and normalized origin rather than raw string prefix matching.

How to confirm the fix worked

Confirm that package manifests and lockfiles resolve webpack to 5.104.1 or later, or that source builds contain commit 24e3c2d2c9f8c6d60810302b2ea70ed86e2863dc or a later fix. Search webpack configuration for experiments.buildHttp and allowedUris to identify exposed builds. Run dependency inventory commands such as npm ls webpack, yarn why webpack, or pnpm why webpack across repositories and build images. Validate mitigations by attempting a controlled build with a crafted userinfo-style HTTP(S) import that appears to match an allowed URI but points to a disallowed test host; patched builds should reject it and should not make the outbound request. Confirm CI/CD egress logs show no requests to disallowed internal, metadata, or unexpected external hosts during webpack builds.

Typical attack path

1. Identify a project or build pipeline using webpack 5.49.0 through 5.104.0 with experiments.buildHttp enabled.
2. Determine or infer the configured allowedUris values used to restrict HTTP(S) imports.
3. Gain influence over source code, dependency content, build configuration, or remote module specifiers used during the build.
4. Craft a URL that begins with an allowed-looking prefix but uses userinfo syntax so the parsed destination host differs from the validated prefix.
5. Trigger the webpack build in CI/CD or a developer environment.
6. Cause the build host to make outbound HTTP(S) requests to an internal endpoint, metadata service, or attacker-controlled server.
7. Optionally return malicious or unexpected JavaScript module content that webpack includes in the final bundle.

How to detect it

Review historical CI/CD logs, developer build logs, web proxy logs, DNS resolver logs, firewall egress logs, and artifact-generation logs for webpack builds that performed outbound HTTP(S) requests using URLs containing userinfo syntax. Focus on builds that enabled experiments.buildHttp and had allowedUris configured. Look for remote module specifiers where an allow-listed prefix is followed by an @ character and then a different host, especially internal IP ranges, localhost, link-local addresses, or cloud metadata endpoints. Investigate any webpack build that contacted 169.254.169.254, 127.0.0.1, ::1, localhost, RFC1918 addresses, or unexpected external domains during dependency resolution or module bundling. Inspect generated bundles and source maps for modules whose sourceURL, comments, or embedded code indicate retrieval from unexpected HTTP(S) origins. Where available, correlate suspicious outbound requests with source commits, pull requests, dependency updates, package install activity, and the exact webpack version used at build time.

• experiments.buildHttp
• buildHttp: true
• allowedUris
• HttpUriPlugin
• ://
• @169.254.169.254
• @127.0.0.1
• @localhost
• @[::1]
• @10.
• @172.16.
• @172.17.
• @172.18.
• @172.19.
• @172.20.
• @172.21.
• @172.22.
• @172.23.
• @172.24.
• @172.25.
• @172.26.
• @172.27.
• @172.28.
• @172.29.
• @172.30.
• @172.31.
• @192.168.
• %40169.254.169.254
• %40127.0.0.1
• %40localhost
• webpack.config.js
• webpack.config.mjs
• webpack.config.cjs

What your security team should do

• Inventory all repositories, build images, and CI/CD workflows using webpack versions 5.49.0 through 5.104.0.
• Prioritize remediation for projects where experiments.buildHttp is enabled or where builds process untrusted contributions, third-party dependencies, generated code, or external module URLs.
• Upgrade webpack to 5.104.1 or later and regenerate lockfiles to ensure the fixed version is actually used in builds.
• Disable experiments.buildHttp where remote HTTP(S) module loading is not strictly required.
• Apply CI/CD egress filtering to prevent build hosts from reaching metadata services, loopback interfaces, private address ranges, and sensitive internal services by default.
• Review recent build logs, proxy logs, DNS logs, and network telemetry for suspicious userinfo-style URLs and unexpected outbound requests during webpack builds.
• Treat unexpected bundle changes or remote module inclusions as a supply-chain investigation, especially if generated artifacts contain code fetched over HTTP(S).