[From nobody Mon Nov 9 08:37:10 2026 Received: (at submit) by bugs.debian.org; 7 Nov 2026 18:24:29 +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=-107.1 required=4.0 tests=ALL_TRUSTED,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, FOURLA,FROMDEVELOPER,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 58; hammy, 150; neutral, 276; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <carnil@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:35906) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xPl5Y-003oUd-3C for submit@bugs.debian.org; Sat, 07 Nov 2026 18:24:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=jeK6CUY7byJFcTM67z46+gaSWoDt3VpNw8Fag2exrfY=; b=PjSejAcZmSzxvPcnlNO0wPG+6U 4oncKQr10fIOsieZWm7Kkn83am2SKBFPbTk03iIoFHeQ3360wTU4rLXm+lSvvUYIXElxyIyporWsq VBmQL2qcXscLjYhSv1aBcDa45VFbuu609LVT/OH0hm58jmDxQU8AgjFiirj7acYUY4U+jEd+X6LsG xyJRFDz+GWgvumW1wuZ8e8b5tpWBLVNwDao0nNHB32C/HD4N+BIeGWQDp8+8hbQLDQSdBvA3/5NNg ivzUqlvYNBf/vXwZhY1NI2vNc7BplHzvgduI/i18QR6r9iod0AzXzQG7YN6K1hNUz9tT9DWZP+Pqd l0EypVMw==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xPl5X-00AFNY-1F for submit@bugs.debian.org; Sat, 07 Nov 2026 18:24:27 +0000 Received: by eldamar.lan (Postfix, from userid 1000) id 9B45EDC0329; Sat, 07 Nov 2026 19:24:26 +0100 (CET) Date: Sat, 7 Nov 2026 19:24:26 +0100 From: Salvatore Bonaccorso <carnil@debian.org> 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: <au9s2kafvZAJ_WPv@eldamar.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Debian-User: carnil Delivered-To: submit@bugs.debian.org Source: node-undici Version: 8.12.2+dfsg+~cs3.2.3-2 X-Debbugs-CC: team@security.debian.org Severity: important Tags: security upstream 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. 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. 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. 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. 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. 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. 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. Regards, Salvatore ]