Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-11-06T10:16:36.913Z",
  "pubdate": "2026-11-06T10:16:36.913Z",
  "executiveSummary": "The vulnerability involves an improper caching mechanism within the undici HTTP client that leads to cross-user private data disclosure. Specifically, when the redirect interceptor and a shared response cache are utilized concurrently, the application fails to correctly partition cache keys based on authentication context. This defect allows sensitive, authenticated response bodies to be erroneously stored under an unauthenticated or generic cache key. Consequently, subsequent requests by different users, including anonymous ones, may retrieve the cached private data of the original authenticated user. This represents a high-impact security flaw, as it facilitates unauthorized access to private information across shared environments. The vulnerability affects versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3 of the undici library. Successful exploitation requires an attacker to trigger a redirect on a shared cache setup, potentially allowing them to observe sensitive data they are not entitled to access. Remediation is achieved by upgrading to the patched versions.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the redirect interceptor within undici when interacting with a shared response cache. When an authenticated request is initiated and subsequently encounters a redirect to a same-origin target, the undici engine manages the cache storage for the final response incorrectly. The vulnerability manifests because the generated cache key for the final response fails to incorporate authentication credentials or headers that define the session's security context.\nSpecifically, the cache key omission occurs because the system fails to account for the Vary header or other session-specific identifiers that would typically differentiate responses intended for authenticated sessions versus anonymous requests. As a result, the response body from an authenticated request is indexed under a cache key that does not reflect its restricted nature. Because the cache is shared, this entry becomes accessible to any subsequent request that resolves to the same key.\nThe attack flow follows a predictable pattern: An initial, legitimate user performs an authenticated request that undergoes a redirect. The resulting private response is cached under a simplified key. A second user, potentially anonymous, then performs a request that maps to the same cache key. Due to the lack of proper segmentation, the undici interceptor services this second request with the cached private response belonging to the first user. The technical failure effectively collapses the logical boundary between distinct user sessions within the caching layer.\nThis vulnerability impacts versions 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3. The exposure is exacerbated in environments where undici is used in a server-side context to proxy or cache requests for multiple users, such as in API gateways or internal microservices handling multi-tenant traffic. The post-exploitation impact is characterized by the unauthorized exposure of PII, session tokens, or other sensitive business data contained within the cached response bodies. The behavior is inherent to the logic of the redirect interceptor and does not require active malicious input, but rather leverages the normal application flow of redirects and shared cache access to perform the information disclosure."
}