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