CVE-2026-84933

What it actually does

undici's cache interceptor neither refuses to store nor strips Set-Cookie on the cache path. In default shared-cache mode, a cacheable response that also carries Set-Cookie (for example Cache-Control public with max-age) is stored and later replayed to any caller whose request matches the same cache key. That discloses one caller's cookies to another caller and lets an untrusted origin inject cookies into responses served from cache, violating the rule that a shared cache must not store cookies. Confidentiality of session and authentication cookies is the primary impact; integrity is limited to cookie injection; availability is unaffected. Attack complexity is high because a shared cache, a response that is both cacheable and cookie-bearing, and a colliding cache key are all required.

Why it matters to the business

Services that use undici's default shared HTTP cache—including Node.js fetch-based apps and downstream packages such as Grafana and Red Hat Node.js 24/26—can leak one user's or service identity's cookies to another consumer, or accept injected cookies, enabling unauthorized access, session fixation, or cross-user data exposure. Multi-tenant and multi-user process-wide caches are the highest operational risk. The issue is not in CISA KEV, has no reported ransomware use, and has no known public exploit about 30 days after publication, so urgency comes from confidentiality impact and how widely undici is embedded rather than from observed in-the-wild attacks.

How an attack unfolds

An attacker who can get undici's shared cache to store a cacheable HTTP response that includes Set-Cookie can later have that header delivered to a different caller that hits the same cache key. Two patterns apply: a legitimate authenticated response that sets a session cookie is cached and then served to another user or service identity, disclosing the cookie; or a malicious or compromised origin returns a cacheable response with an attacker-controlled Set-Cookie, which the shared cache then attaches to subsequent callers (cookie injection / session fixation). No privileges or user interaction are required once a vulnerable shared cache, a cookie-bearing cacheable response, and a colliding cache key exist. No named threat actors or campaigns are associated, and exploit maturity is none.

How to fix it

Upgrade undici to 7.29.1 on the 7.x line or 8.10.2 on the 8.x line. For Red Hat packaged products, apply RHSA-2026:54389: grafana12-4-main 12.4.10-0.2.hum1, nodejs24-main 11.16.0-1.24.18.1.0.2.2.hum1, and nodejs26-main 26.7.0-1.5.2.hum1. If an immediate upgrade is not possible, disable the shared cache interceptor, switch to a private (non-shared) cache, or ensure responses that carry Set-Cookie are not stored; treat those as temporary mitigations only. Rebuild and redeploy any application, image, or product that vendors undici so the patched library is what actually loads at runtime.

How to confirm the fix worked

Confirm the loaded undici version is 7.29.1, 8.10.2, or later via lockfiles, npm ls undici, SBOMs, or the Node.js distribution package version. On Red Hat systems, verify the RHSA-2026:54389 NVRs above are installed. After patching, confirm that cacheable responses containing Set-Cookie are not stored in or served from the shared cache and that cookie-bearing responses are not reused across callers. Recursively check dependency trees for transitive undici copies that were not upgraded.

Typical attack path

1. Identify an application or product using undici 7.x before 7.29.1 or 8.x before 8.10.2 with the default shared cache interceptor enabled.
2. Arrange for a cacheable HTTP response that includes a Set-Cookie header to be stored under a shared cache key, either from a legitimate authenticated flow or from an untrusted origin.
3. A later request from a different caller that matches the same cache key is served the stored response, including the original or injected Set-Cookie.
4. A disclosed session cookie can be reused to impersonate the original caller, or an injected cookie can fixate subsequent callers onto an attacker-chosen session.

How to detect it

This issue leaves no distinctive malware artifacts and has no associated named threat actors. Review application, reverse-proxy, and Node.js access logs for cache hits that returned Set-Cookie to clients that never authenticated to the origin, sudden appearance of unfamiliar session cookies, or multiple distinct users presenting the same session identifier. In Grafana and other undici-consuming products, look for anomalous authentication or session-fixation symptoms on shared cache keys. If undici or Node.js cache debug logging was enabled, inspect historical store and retrieve events. Correlate any such events with contact to untrusted origins that returned public/max-age caching together with Set-Cookie. Treat findings as possible mis-caching rather than a known campaign.

What your security team should do

• Inventory Node.js services, Grafana instances, and Red Hat Node.js 24/26 hosts shipping undici 7.0.0 through before 7.29.1 or 8.0.0 through before 8.10.2.
• Patch to undici 7.29.1 or 8.10.2, or apply RHSA-2026:54389, and redeploy so the patched library is loaded.
• Until patched, disable or isolate the shared cache interceptor so cookie-bearing responses cannot be reused across callers.
• Hunt application and access logs for unexpected session reuse, cross-user cookies, and cache hits that include Set-Cookie.
• Update SBOMs and lockfiles so transitive undici copies cannot regress on the next build.