CVE-2026-84933 in undici
Summary
by MITRE • 09/04/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/05/2026
The vulnerability in the undici HTTP client library represents a critical failure in cache security logic, specifically within its interceptor mechanism responsible for handling shared caching scenarios. In standard web architecture, shared caches are designed to store and serve responses to multiple clients based on request keys, optimizing performance by reducing redundant network requests. However, this optimization introduces significant privacy risks if sensitive data such as session cookies is inadvertently cached and served to unintended recipients. The flaw lies in the fact that undici's cache interceptor does not properly inspect or handle the Set-Cookie response header during any stage of its caching process. This oversight means that when a server responds with both cacheable directives, such as public and max-age, and includes a Set-Cookie header indicating user-specific session data, the library proceeds to store this entire response in the shared cache without modification or refusal.
From a technical perspective, the core issue is the absence of validation logic that checks for sensitive headers before committing a response to the cache storage layer. According to HTTP caching specifications and best practices defined by industry standards like CWE-524, which covers the use of passwords or passphrases in cookies without proper security controls, shared caches must strictly avoid storing responses containing Set-Cookie headers unless explicitly permitted by specific directives that guarantee privacy, such as private cache control settings. Undici's default behavior operates in shared cache mode, where it assumes broad accessibility for cached content. Consequently, when a response marked with public visibility and a long max-age duration includes a Set-Cookie header, the library stores the full payload including the cookie value. This creates a direct pathway for information disclosure because subsequent requests matching the same cache key will receive this stored response verbatim.
The operational impact of this vulnerability is severe, leading to cross-user session hijacking and unauthorized data exposure. An attacker who can influence or predict request patterns may trigger caching of responses containing their own cookies, but more dangerously, an untrusted server could inject malicious cookies into cached responses that are then served to all subsequent callers matching the cache key. This allows for cookie injection attacks where a victim's browser receives session identifiers belonging to another user or crafted by an attacker. Such behavior violates fundamental security principles regarding isolation of client-side state and can lead to complete compromise of user accounts, as the victim’s application will authenticate using cookies that were originally issued to a different entity. This aligns with ATT&CK technique T1539, which involves stealing web session credentials, highlighting how improper cache handling facilitates credential theft in distributed systems.
To mitigate this risk, it is imperative for developers and system administrators to upgrade undici immediately to version 7.29.1 or 8.10.2, where the caching logic has been corrected to properly refuse storage of responses containing Set-Cookie headers in shared cache modes. Until an upgrade can be performed, temporary workarounds include disabling shared caching entirely by configuring the client to use private caches only, although this may impact performance. Additionally, ensuring that server-side applications do not send public cache directives for endpoints returning sensitive session data provides a secondary layer of defense. The root cause remains in the library's default configuration and implementation details, making an update the most effective long-term solution to restore compliance with HTTP caching security standards and prevent further disclosure of user credentials through cached responses.