Description

undici's cache interceptor does not handle the Set-Cookie response header anywhere in its cache path, so it neither refuses to store nor strips that header. In shared cache mode, which is the default, an otherwise cacheable response that carries a Set-Cookie header, for example one marked with a public and max-age directive, is stored and then re-served to a later caller that matches the same cache key. As a result one caller's cookie is disclosed to a different caller, and an untrusted server can inject cookies into cached responses served to all subsequent callers. This violates the requirement that a shared cache must not store cookies. This affects undici versions from 7.0.0 up to 7.29.1 and from 8.0.0 up to 8.10.2. Users should upgrade to undici 7.29.1 or 8.10.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-04T17:17:01.973Z",
  "pubdate": "2026-09-04T17:17:01.973Z",
  "executiveSummary": "The undici HTTP client library contains a critical vulnerability within its cache interceptor where the 'Set-Cookie' header is neither stripped nor refused during the caching process.\nBecause the default configuration employs a shared cache mode, responses containing session-sensitive 'Set-Cookie' headers are stored and subsequently re-served to different users requesting the same cache key.\nThis vulnerability leads to unauthorized information disclosure, where one user's session credentials or authentication cookies can be exposed to other callers. Furthermore, it allows malicious servers to perform cross-user cookie injection, potentially facilitating session fixation or hijacking.\nThe flaw affects undici versions 7.0.0 through 7.29.0 and 8.0.0 through 8.10.1. The risk is high for applications utilizing the built-in cache interceptor in shared environments, as it violates fundamental HTTP specifications regarding the handling of sensitive headers in shared caches.\nSuccessful exploitation requires an attacker to control or influence a server response that undici caches, requiring no specific privileges from the attacker other than the ability to return a response with specific caching headers.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper implementation of the cache interceptor logic within the undici library. Specifically, the component responsible for processing and storing HTTP responses fails to perform header filtering or validation regarding the 'Set-Cookie' field.\nUnder the RFC 9111 specification, shared caches must not store or serve responses that contain 'Set-Cookie' headers to subsequent users, as this presents a severe security risk. The undici implementation incorrectly treats responses marked with public cache control directives (such as 'public' and 'max-age') as universally cacheable, regardless of the presence of sensitive session-related headers.\nThe attack flow follows a predictable pattern: 1) An initial request is made to a server controlled or compromised by an attacker. 2) The attacker returns an HTTP response containing a 'Set-Cookie' header alongside cache-control headers that mark the response as valid for caching (e.g., 'public', 'max-age=3600'). 3) The undici cache interceptor stores this response in its internal shared cache, including the 'Set-Cookie' header. 4) A legitimate, subsequent caller makes a request that results in a cache hit for the same key. 5) Undici serves the cached response to the second caller, effectively injecting the attacker's cookie into the second caller's context or disclosing a previous user's cookie if the cache was populated by a sensitive request.\nThis behavior facilitates two primary attack vectors: Cookie Disclosure, where sensitive session data is leaked between users, and Cookie Injection, where an attacker dictates the session state of an unsuspecting client. This vulnerability impacts undici versions 7.0.0 up to 7.29.1 (exclusive) and 8.0.0 up to 8.10.2 (exclusive).\nThe vulnerability is present in the cache interceptor component. It is triggered during standard network interactions where the library is configured to cache responses. Exploitation does not require authentication or elevated privileges, as it stems from the library's internal handling of response headers during the standard request/response lifecycle. Any application that relies on undici's shared caching mechanism for handling requests to untrusted or potentially malicious origins is exposed to this leakage."
}