undici is an HTTP client library for Node.js. In versions 7.15.0 through 7.30.0 and 8.0.0 through 8.12.1, its fetch() implementation verifies Subresource Integrity metadata by matching the algorithm token against a lowercase-only set, even though the SRI specification defines the token by its ASCII-lowercase form, so a valid but non-lowercase token such as an uppercase or mixed-case SHA256 is treated as unknown and skipped. When no recognized algorithm remains, undici treats the integrity list as empty and accepts the response, so a server returning a body that does not match the pinned digest passes the check. An attacker who controls only the response body can therefore deliver attacker-controlled bytes to an application that pinned a valid uppercase or mixed-case SRI token, with no integrity error, affecting response integrity only. The issue is fixed in undici 7.30.1 and 8.12.2, which normalize the algorithm token to ASCII lowercase before validation, and users should upgrade to one of those versions or later. As a workaround, use lowercase algorithm tokens such as sha256, sha384, or sha512 in integrity metadata.
Weakness
The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
Affected Software
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Undici | Nodejs | 7.15.0 (including) | 7.30.1 (excluding) |
| Undici | Nodejs | 8.0.0 (including) | 8.12.2 (excluding) |
| Red Hat Hardened Images | RedHat | nodejs26-main-11.20.0-1.26.11.1.0.4.hum1 | * |
| Red Hat Hardened Images | RedHat | nodejs26-main-26.11.1-0.4.hum1 | * |
| Red Hat Hardened Images | RedHat | nodejs24-main-11.19.0-1.24.21.0.1.5.hum1 | * |
| Red Hat Hardened Images | RedHat | nodejs24-main-24.21.0-1.5.hum1 | * |
| Node-undici | Ubuntu | upstream | * |
Extended Description
Improperly handled case sensitive data can lead to several possible consequences, including:
Potential Mitigations
- 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.