CVE-2025-68157

What it actually does

Webpack versions 5.49.0 through versions before 5.104.0 contain an allow-list enforcement flaw in the experimental HTTP(S) module resolver used when experiments.buildHttp is enabled. The resolver validates allowedUris for the originally requested URL, but after following HTTP 30x redirects it does not re-check whether the final destination is still permitted. A user who can influence build inputs, dependency source, imported module URLs, or an allowed remote endpoint can cause the build process to fetch content from a non-allowed URL. Depending on the build machine’s network reachability, this can result in build-time server-side request forgery to internal services and/or inclusion of untrusted redirected module content into generated bundles. The issue has low exploitation likelihood in general because it requires the experimental feature to be enabled, a build that imports HTTP(S) resources, user interaction or build execution, and some level of control over imported content or redirect behavior.

Why it matters to the business

The main business risk is compromise of build integrity: software artifacts may include code fetched from a location that was not intended or trusted. In environments where build systems have access to internal networks, the flaw may also allow probing or limited retrieval from internal-only endpoints during builds. This can affect CI/CD trust, release integrity, and confidentiality of internal metadata or services reachable from build workers. The vulnerability is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so remediation should be prioritized based on whether affected webpack versions are used with experiments.buildHttp enabled in build pipelines.

How an attack unfolds

An attacker first identifies a project or dependency chain that builds with webpack 5.49.0 or later before 5.104.0 and has experiments.buildHttp enabled. They then arrange for a build-time import to reference an HTTP(S) URL that matches the configured allowedUris policy. That allowed URL returns an HTTP redirect, such as 301, 302, 307, or 308, to a different destination outside the allow-list. Because the vulnerable resolver only validates the initial URL, webpack follows the redirect and treats the final response as module source. If the redirected location is attacker-controlled, malicious or unexpected code can be bundled into the output. If the redirected location targets an internal service reachable from the build host, the build process may issue requests to internal-only endpoints, creating an SSRF condition with potential information disclosure depending on the response handling and bundling behavior.

How to fix it

Upgrade webpack to version 5.104.0 or later. For source-based deployments, ensure the code includes commit 505a5e744fbcf4471ddb534bf1d4aebea9643c1b or a later equivalent fix. If immediate upgrade is not possible, disable experiments.buildHttp, remove HTTP(S)-based imports from builds, or ensure builds only fetch dependencies from local package registries and pinned artifact sources. Treat redirects from remote module sources as untrusted and block them at egress controls where feasible. Restrict CI/CD and developer build workers from reaching sensitive internal metadata services, cloud control-plane endpoints, and private administrative interfaces. Review allowedUris configuration and avoid trusting broad domains or services that can be influenced by untrusted users.

How to confirm the fix worked

Confirm the installed webpack version is 5.104.0 or later by checking package manifests, lockfiles, and runtime package resolution, for example with npm ls webpack, yarn why webpack, pnpm why webpack, or equivalent software composition analysis tooling. Search webpack configuration for experiments.buildHttp and verify it is disabled where not explicitly required. If the feature must remain enabled, run a controlled test using an allowed URL that redirects to a non-allowed URL and confirm the build blocks or rejects the redirected destination. Review CI/CD build logs and dependency lockfiles to ensure no HTTP(S) imports are resolved through redirecting endpoints. Validate network egress policies from build workers to ensure internal-only endpoints cannot be reached unnecessarily.

Typical attack path

1. Find a target project, package, or build pipeline using webpack versions 5.49.0 through before 5.104.0.
2. Confirm or infer that experiments.buildHttp is enabled and HTTP(S) imports are used during the build.
3. Gain influence over an imported HTTP(S) module URL, a dependency that contains such an import, or a server already permitted by allowedUris.
4. Serve a permitted initial URL that responds with an HTTP 30x redirect to a non-allowed external or internal URL.
5. Trigger a webpack build in CI, local development, or release automation.
6. Webpack validates only the initial allowed URL, follows the redirect, and fetches the final disallowed destination.
7. The fetched response is processed as module source and may be bundled, or the build machine makes unintended requests to internal services.

How to detect it

To assess prior exploitation, focus on build-time telemetry rather than production application logs. Review CI/CD logs, webpack build output, proxy logs, DNS logs, firewall egress logs, and artifact repository logs for webpack builds that made HTTP(S) requests followed by redirects to domains or IP ranges outside approved dependency sources. Search source repositories and dependency code for HTTP(S) import statements used with webpack’s buildHttp feature. Investigate any build worker network connections to internal address ranges, cloud metadata endpoints, localhost services, or unexpected external hosts occurring during webpack compilation. Compare generated bundles from affected build periods against trusted source inputs to identify injected or unexpected modules. If available, correlate process telemetry for node or webpack processes initiating outbound HTTP(S) connections during builds, especially connections involving 301, 302, 303, 307, or 308 redirects. Because the vulnerability does not create a unique malware artifact, detection depends heavily on identifying suspicious redirect chains, unexpected remote module sources, and anomalous build-worker egress.

• experiments.buildHttp
• buildHttp: true
• allowedUris
• import "http://
• import 'http://
• import "https://
• import 'https://
• HttpUriPlugin
• HTTP 301
• HTTP 302
• HTTP 303
• HTTP 307
• HTTP 308
• 169.254.169.254
• metadata.google.internal
• 100.100.100.200
• 169.254.170.2
• 127.0.0.1
• localhost
• webpack://
• node_modules/webpack/lib/schemes/HttpUriPlugin.js

What your security team should do

• Inventory all projects and build pipelines using webpack and identify versions 5.49.0 through before 5.104.0.
• Prioritize remediation for repositories where experiments.buildHttp is enabled or where builds import modules over HTTP(S).
• Upgrade webpack to 5.104.0 or later, or apply a build containing commit 505a5e744fbcf4471ddb534bf1d4aebea9643c1b.
• Disable experiments.buildHttp unless there is a documented business need for remote HTTP(S) module imports.
• Harden CI/CD worker egress so build jobs cannot reach cloud metadata services, internal admin panels, source-control management APIs, secrets stores, or private service endpoints unless explicitly required.
• Review recent build logs for HTTP 30x redirects during webpack builds and unexpected requests to internal IP ranges or non-approved domains.
• Pin and mirror build dependencies through trusted registries or artifact repositories rather than fetching module source directly over arbitrary HTTP(S) URLs.
• Add supply-chain review checks for imports beginning with http:// or https:// in source code and dependencies.