Source: node-undici X-Debbugs-CC: [email protected] Severity: important Tags: security
Hi, The following vulnerabilities were published for node-undici. CVE-2026-116592[0]: | undici is an HTTP client for Node.js. In versions 7.30.1 and 8.12.2 | through 8.12.3, when an originless Agent composes the redirect and | shared cache interceptors, undici decides whether to store the final | response under the original request key by inspecting only the final | redirect hop, which bypasses the earlier fix for CVE-2026-109829 | that compared only the initial and final origins. A redirect that | bounces through an untrusted origin and returns to the trusted | origin is still cached under the trusted key, an intermediate hop's | Vary is dropped so a response that varies on Authorization or Cookie | can be served to a different user, and an intermediate hop's no- | cache or default-uncacheable status is ignored so a non-storable | redirect is laundered into a cacheable entry. An attacker who | controls a redirect target from a trusted URL can poison the cached | entry for that URL or have a private, per-user response served to a | later caller. The issue is fixed in undici 7.30.2 and 8.12.4, and | users should upgrade to one of those versions or later. As a | workaround, compose the interceptors as cache then redirect, use | per-origin dispatchers and cache stores, or disable shared caching | on redirect-capable requests. https://github.com/nodejs/undici/security/advisories/GHSA-mqg3-3v4r-cm32 CVE-2026-116630[1]: | undici is an HTTP client for Node.js. In versions 7.0.0 through | 7.30.1 and 8.0.0 through 8.12.3, when an Agent composes the redirect | and shared cache interceptors, a cached response that is revalidated | with a conditional request can be validated by a 304 Not Modified | from a different origin. When the origin that stored the response | redirects the conditional revalidation request to another origin, | the redirect handler strips origin-bound credential headers but not | the cache-generated If-None-Match or If-Modified-Since validators, | so the redirect destination receives the original origin's validator | and undici treats its 304 as successful revalidation of the stored | representation. As a result, a shared cache can serve the original | origin's stored authenticated response, including one gated by | Authorization, to a later unauthenticated caller. The issue is fixed | in undici 7.30.2 and 8.12.4, and users should upgrade to one of | those versions or later. As a workaround, compose the interceptors | as cache then redirect, use per-origin dispatchers and cache stores, | or disable shared caching on redirect-capable requests. https://github.com/nodejs/undici/security/advisories/GHSA-5rm8-gv32-r954 CVE-2026-120222[2]: | undici is an HTTP client for Node.js. In versions 7.0.0 through | 7.30.1 and 8.0.0 through 8.12.3, when the cache interceptor is | composed with a downstream handler that throws during response | processing (such as the built-in dump interceptor exceeding its | maxSize, or the decompress interceptor rejecting more than five | Content-Encoding values), a throw raised asynchronously while a | cached response is replayed escapes as an uncaught exception or | unhandled promise rejection and terminates the Node.js process. A | malicious or compromised HTTP server can crash any such client by | serving a cacheable response that triggers the throw on replay, | including on a 304 revalidation of a stale entry, so the impact is | availability only. The issue is fixed in undici 7.30.2 and 8.12.4, | and users should upgrade to one of those versions or later. As a | workaround, avoid composing the cache interceptor with a response | handler that throws during response processing until upgrading. https://github.com/nodejs/undici/security/advisories/GHSA-3g9m-rv3r-w5w2 CVE-2026-120415[3]: | undici is an HTTP client for Node.js. In versions 7.0.0 through | 7.30.1 and 8.0.0 through 8.12.3, the redirect interceptor strips | sensitive headers such as Authorization, Cookie, Proxy- | Authorization, and Host when a request is redirected to a different | origin, but when request headers are supplied as an array of name | and value tuples (a valid documented input, for example from | Object.entries), the redirect handler misreads them as a flat list | so the header names never match and the sensitive headers are not | removed. If a header-normalizing interceptor such as cache or | deduplicate is composed outside the redirect interceptor, it then | serializes the retained headers onto the cross-origin request, | disclosing the caller's origin-bound credentials to the unrelated | redirect destination. This is a representation-dependent bypass of | the cross-origin header stripping added in CVE-2024-30260. The issue | is fixed in undici 7.30.2 and 8.12.4, and users should upgrade to | one of those versions or later. As a workaround, supply request | headers as a plain object or a flat name and value array rather than | an array of tuples, or compose the redirect interceptor outside the | normalizing interceptor. https://github.com/nodejs/undici/security/advisories/GHSA-9v6h-8rgp-m69f CVE-2026-120423[4]: | undici is an HTTP client for Node.js. In versions 7.15.0 through | 7.30.1 and 8.0.0 through 8.12.3, fetch verifies Subresource | Integrity metadata by splitting the integrity string on a single | space, but the SRI grammar separates metadata by ASCII whitespace, | which also includes the horizontal tab. An integrity value whose | digest is preceded by a tab or other ASCII whitespace is parsed as a | single unrecognized token and skipped, and when no recognized | algorithm remains undici treats the integrity list as empty and | accepts the response, so a server returning a body different from | the pinned digest passes the check. An application that pins a | response with a valid but whitespace-surrounded SRI value receives | attacker-controlled bytes with no integrity error, and the attacker | needs only to control the response body, not the integrity metadata. | The issue is fixed in undici 7.30.2 and 8.12.4, and users should | upgrade to one of those versions or later. As a workaround, supply | SRI integrity metadata without surrounding whitespace, using a | single space to separate multiple digests. https://github.com/nodejs/undici/security/advisories/GHSA-r4pc-4jcp-7pqc CVE-2026-120474[5]: | undici is an HTTP client for Node.js. In versions 7.0.0 through | 7.30.1 and 8.0.0 through 8.12.3, when the redirect interceptor and a | shared response cache are used together, an authenticated request | that is redirected to a same-origin target has the final response | stored under the original request's cache key. That key omits the | credential and carries no Vary header, so a later anonymous or | different user can be served the first user's private response body. | This results in cross-user disclosure of cached private responses. | The issue is fixed in undici 7.30.2 and 8.12.4, and users should | upgrade to one of those versions or later. https://github.com/nodejs/undici/security/advisories/GHSA-7xg3-fphp-28hg If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-116592 https://www.cve.org/CVERecord?id=CVE-2026-116592 [1] https://security-tracker.debian.org/tracker/CVE-2026-116630 https://www.cve.org/CVERecord?id=CVE-2026-116630 [2] https://security-tracker.debian.org/tracker/CVE-2026-120222 https://www.cve.org/CVERecord?id=CVE-2026-120222 [3] https://security-tracker.debian.org/tracker/CVE-2026-120415 https://www.cve.org/CVERecord?id=CVE-2026-120415 [4] https://security-tracker.debian.org/tracker/CVE-2026-120423 https://www.cve.org/CVERecord?id=CVE-2026-120423 [5] https://security-tracker.debian.org/tracker/CVE-2026-120474 https://www.cve.org/CVERecord?id=CVE-2026-120474 Please adjust the affected versions in the BTS as needed.
