undici vulnerable to cross-user cookie disclosure via Set-Cookie caching in shared cachesGHSA-2jfj-6hjv-fm6j
MEDIUMFix: nodejs/undici@b6c5a00GHSA-2jfj-6hjv-fm6j is a medium-severity (CVSS 6.5) Information Exposure vulnerability in undici. A fix is available for undici — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-2jfj-6hjv-fm6j.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2jfj-6hjv-fm6j by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
undicinpmDescription
Impact
undici's interceptors.cache() does not handle Set-Cookie in the cache path. In shared-cache mode (type: 'shared', the default), a cacheable response (for example Cache-Control: public, max-age=...) carrying a Set-Cookie header is stored, and the stored Set-Cookie is re-served to a later caller that hits the same cache key. This exposes one user's cookie to another caller and lets an untrusted upstream inject cookies into cached responses served to all subsequent callers, violating RFC 6265 section 7.2 (a shared cache must not store cookies). Applications using the shared cache interceptor against untrusted or multi-user upstreams are affected. Private caches (type: 'private') are not affected.
Patches
Upgrade to 7.29.1 or 8.10.2. In shared-cache mode, undici no longer stores or re-serves responses containing Set-Cookie, including previously cached entries and revalidation paths.
Workarounds
Use a private cache (type: 'private') for per-user responses, or avoid caching responses that set cookies. Applications acting as shared caches should strip Set-Cookie from responses before caching.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | undici | ≥ 7.0.0&&< 7.29.1 | 7.29.1npm install undici@7.29.1 |
| 📦npm | undici | ≥ 8.0.0&&< 8.10.2 | 8.10.2npm install undici@8.10.2 |
Affected Products
undicinodejsDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for undici, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update undici to 7.29.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2jfj-6hjv-fm6j is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This flaw affects applications that use undici's shared-cache interceptor (interceptors.cache(), type: 'shared', which is the default) against untrusted or multi-tenant upstream servers. In that configuration, undici stores and re-serves the Set-Cookie header of cached responses, allowing one user's session cookie to…
Upgrade to undici 7.29.1 or 8.10.2 (or later), where the shared cache interceptor no longer stores or re-serves responses containing Set-Cookie. Where an immediate upgrade is not possible: use a private cache (type: 'private') for per-user responses instead of the shared cache; avoid caching responses that carry a Set-Cookie header; or, if your service itself acts as a shared cache in front of an untrusted origin, strip Set-Cookie from upstream responses before caching them.Source: Red Hat security advisory for GHSA-2jfj-6hjv-fm6j (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | nodejs26-main-11.19.0-1.26.7.0.1.5.2.hum1 | RHSA-2026:54389 |
| Red Hat Hardened Images | nodejs24-main-11.16.0-1.24.18.1.0.2.2.hum1 | RHSA-2026:54438 |
| Red Hat Hardened Images | grafana12-4-main-12.4.10-0.2.hum1 | RHSA-2026:66008 |
Frequently Asked Questions
Is GHSA-2jfj-6hjv-fm6j in your dependencies?
Find it across npm, including transitive dependencies.