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 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-11-06T11:17:05.497Z",
  "pubdate": "2026-11-06T11:17:05.497Z",
  "executiveSummary": "A critical cache handling vulnerability exists in the Undici HTTP client for Node.js, specifically affecting the interaction between redirect and shared cache interceptors.\nThe vulnerability allows for improper validation of cached responses, where a 304 Not Modified response from a malicious or secondary origin is incorrectly accepted as a revalidation for a cached resource originating from a different, authenticated source.\nThis flaw leads to potential information disclosure, as a shared cache may serve sensitive, authenticated responses—such as those protected by Authorization headers—to unauthenticated third-party callers.\nAffected versions include Undici 7.0.0 through 7.30.1 and 8.0.0 through 8.12.3.\nExploitation requires an attacker to influence the revalidation flow during an HTTP redirect sequence. The risk is significant for applications utilizing shared caching mechanisms, as it bypasses origin-bound security controls and credential isolation policies.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper sequencing of the redirect and shared cache interceptors within the Undici Agent. When these components are composed, the redirect handler fails to sufficiently sanitize cache-generated validation headers during cross-origin redirections.\nThe attack flow initiates when the Undici client attempts a conditional revalidation of a previously cached response. When the original origin issues a redirect for this revalidation request, the redirect handler appropriately strips origin-bound credentials, such as the 'Authorization' header, to prevent leakage to the new destination.\nHowever, the handler neglects to purge cache-specific conditional request headers, specifically 'If-None-Match' or 'If-Modified-Since'. Consequently, these headers are forwarded to the redirect destination.\nIf the attacker controls the redirect destination, they can provide a '304 Not Modified' response back to the client. The Undici cache interceptor incorrectly interprets this 304 response as a successful revalidation of the original, authenticated representation stored in the cache. Because the validator remains valid in the context of the client's state machine, Undici marks the cached entry as fresh.\nOnce the cache entry is erroneously revalidated, subsequent requests to the cached resource—which may contain sensitive, authenticated content—can be served directly from the shared cache to any caller, regardless of the caller's privilege level or lack of valid authentication credentials.\nThis logic flaw effectively bypasses the security boundary between different origins. The vulnerability exists within the interaction logic of the request dispatching pipeline when shared caching is enabled alongside redirection logic. The exposure is network-based, as it relies on the client's interaction with a server (or redirected server) that influences the cache state.\nSuccessful exploitation results in unauthorized access to cached data. Post-exploitation impact includes the exposure of sensitive API responses, private user data, or session-specific information that was cached under an authenticated session context."
}