[From nobody Mon Nov 9 08:37:08 2026 Received: (at submit) by bugs.debian.org; 7 Nov 2026 19:54:59 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=4.0 tests=BAYES_00,FOURLA, FVGT_m_MULTI_ODD,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 44; hammy, 150; neutral, 337; spammy, 0. spammytokens: hammytokens:0.000-+--UD:security-tracker.debian.org, 0.000-+--security-tracker.debian.org, 0.000-+--securitytrackerdebianorg, 0.000-+--H*r:jmm, 0.000-+--sk:team@se Return-path: <jmm@inutil.org> Received: from inutil.org ([51.38.114.215]:34842 helo=vps-b7ad3695.vps.ovh.net) by buxtehude.debian.org with esmtp (Exim 4.96) (envelope-from <jmm@inutil.org>) id 1xPmV9-00402H-1f for submit@bugs.debian.org; Sat, 07 Nov 2026 19:54:59 +0000 Received: from soju.fritz.box (p5dc5d518.dip0.t-ipconnect.de [93.197.213.24]) by vps-b7ad3695.vps.ovh.net (Postfix) with ESMTPSA id 45F23F27 for <submit@bugs.debian.org>; Sat, 7 Nov 2026 19:54:58 +0000 (UTC) Received: from jmm by soju.fritz.box with local (Exim 4.100.1) (envelope-from <jmm@soju.westfalen.local>) id 1xPmV7-000000008mX-49CF for submit@bugs.debian.org; Sat, 07 Nov 2026 20:54:58 +0100 Date: Sat, 7 Nov 2026 20:54:57 +0100 To: submit@bugs.debian.org Subject: node-undici: CVE-2026-116592 CVE-2026-116630 CVE-2026-120222 CVE-2026-120415 CVE-2026-120423 CVE-2026-120474 Message-ID: <au-CEeMN45SepaSa@pisco.westfalen.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline From: =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= <jmm@inutil.org> Delivered-To: submit@bugs.debian.org Source: node-undici X-Debbugs-CC: team@security.debian.org 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. ]