CVE-2026-84933 is a medium severity (CVSS 6.5) information exposure flaw in the undici npm package. Its shared cache interceptor stores responses that carry Set-Cookie and serves them to other callers. Upgrade to undici 7.29.1 or 8.10.2, or switch to a private cache.
What's affected
The record and the GitHub security advisory agree. The affected package is undici on npm, from 7.0.0 up to but not including 7.29.1, and from 8.0.0 up to but not including 8.10.2. The patched versions are 7.29.1 and 8.10.2. The advisory rates the issue Moderate, and the record scores it 6.5, so the two match.
The flaw is in the cache interceptor. In shared cache mode, which is the default, a cacheable response that carries a Set-Cookie header is stored, and the cookie is served again to a later caller that hits the same cache key. One user's cookie can reach another caller, and an untrusted server can plant cookies in cached responses served to everyone after. The advisory says private caches are not affected.
After the fix, shared mode no longer stores or serves responses with Set-Cookie, including entries that were cached earlier and revalidation paths.
How to check if you're exposed
List every version of undici in your project tree, including copies pulled in by other packages:
npm ls undici
npm explain undici
For yarn or pnpm, use the equivalent why command. A copy in range 7.0.0 up to 7.29.0, or 8.0.0 up to 8.10.1, is affected. This advisory is about the undici package from npm. Node.js ships its own copy for its built-in fetch, which is tracked separately, so check Node's release notes for that.
Then look at how you use the cache. Search your code for the cache interceptor:
grep -rn "interceptors.cache" --include=*.js --include=*.ts .
You are only exposed if you use the cache interceptor in shared mode against upstreams that set cookies, for example a backend for frontend service that serves many users.
What to do now
- Upgrade undici to 7.29.1 or 8.10.2, matching your major version, and commit the updated lock file.
- If you cannot upgrade yet, use a private cache for per-user responses, as the advisory suggests, or keep responses that set cookies out of the cache.
- Strip Set-Cookie from responses before they reach any shared cache you operate.
- Clear the existing cache after upgrading, in case it holds stored entries with cookies.
- Add a dependency scan to CI so the next advisory in a transitive package is flagged.
Why it matters
This is exposure of sensitive information, CWE-200, through a cache that stores data that should not be shared, CWE-524. RFC 6265 says a shared cache must not store cookies, because a cookie belongs to one user. undici's interceptor did not handle the header, so it stored and replayed it like any other header.
The harm depends on your architecture. A service that fetches from an API for many users, and caches in shared mode, can hand one user's session cookie to another. The advisory also notes the reverse: a hostile upstream can set cookies that every later caller receives. The record does not list this CVE as exploited in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I use a private cache?
Not by this flaw. The advisory says private caches are not affected.
Is the default configuration vulnerable?
Shared mode is the default, per the advisory, so using the cache interceptor without options puts you in shared mode.
Sources
Last reviewed: 18 October 2026.
