GHSA-f72v-6w45-q472 CVE-2026-109841

undici vulnerable to Subresource Integrity bypass via non-lowercase algorithm tokens

High npm

Severity: 5.9 / 10; High · CVSS 3.1
Exploit chance (EPSS): 0.25%; Chance of exploitation in the next 30 days. Higher than 16.69% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-178 Improper Handling of Case Sensitivity
Fix: 7.30.1; Upgrade undici to this version or later

Description

Impact

undici's fetch() verifies Subresource Integrity (SRI) metadata by looking up the algorithm token in a lowercase-only set, but the SRI specification defines a valid token by its ASCII-lowercase form. A correct but non-lowercase token such as SHA256-... or Sha256-... is therefore treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server that returns a body different from the pinned digest passes the check.

An application that pins a response with a valid uppercase or mixed-case SRI token receives attacker-controlled bytes with no integrity error. The attacker needs only to control the response body, not the application's integrity metadata. The issue affects response integrity only. The regression was introduced in undici 7.15.0; releases 7.14.0 and earlier lowercase the token and are not affected.

Patches

Upgrade to 7.30.1 or 8.12.2. undici now normalizes the algorithm token to ASCII lowercase before validating it and before selecting the strongest algorithm, so case variants of SHA-256, SHA-384, and SHA-512 are verified correctly.

Workarounds

Use lowercase algorithm tokens (sha256, sha384, sha512) in integrity metadata.

Affected versions

npm

Package	Vulnerable	Fixed in
undici	`>= 7.15.0, < 7.30.1`	`7.30.1`
undici	`>= 8.0.0, < 8.12.2`	`8.12.2`
undici	`>= 7.15.0, < 7.30.1`	`7.30.1`
undici	`>= 8.0.0, < 8.12.2`	`8.12.2`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

undici npm → `7.30.1`

npm

npm install undici@7.30.1

yarn

yarn add undici@7.30.1

pnpm

pnpm add undici@7.30.1

Severity breakdown

CVSS 3.1 5.9

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

Attack vector: Network
Attack complexity: High
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: None
Integrity: High
Availability: None

Weakness

CWE-178: Improper Handling of Case Sensitivity

The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.

How to prevent it

Architecture and Design: Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.

References

Advisories

Fixes and patches

Packages

github.com/nodejs/undici

Timeline

Oct 15, 2026 Published
Oct 23, 2026 Last updated by the source
Nov 1, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-55wc-3pg8-jfw6 undici vulnerable to Denial of Service via unhandled exception in the decompress interceptor	High	Also affects undici
GHSA-qrxm-fqhp-jwvm undici vulnerable to Denial of Service via TLS 1.2 certificate-changing renegotiation	High	Also affects undici
GHSA-9fm3-97px-rjf6 undici WebSocket client vulnerable to Denial of Service via unbounded automatic PONG buffering	High	Also affects undici
GHSA-4qv8-2p9j-2685 undici vulnerable to Denial of Service via unbounded memory in the EventSource parser	High	Also affects undici
GHSA-xjj6-f33q-929c undici vulnerable to Denial of Service via unhandled error on excessive content-encodings	High	Also affects undici
GHSA-4w7w-5xrc-9h26 undici vulnerable to cache poisoning and cross-user disclosure via cross-origin redirects	Critical	Also affects undici
GHSA-2m5v-pch6-74hx undici vulnerable to TLS certificate validation bypass via dropped tls options in Agent	Critical	Also affects undici
GHSA-qq8j-7v2v-3rwp undici WebSocket client vulnerable to Denial of Service via failed HTTP/2 handshake	High	Also affects undici

Credits: Kushalkhemka, UlisesGascon, mayank-jangid-moon, mcollina, opensec-intelligence, skigeek16

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor