MediumGHSA-2jfj-6hjv-fm6jCVE-2026-84933

undici vulnerable to cross-user cookie disclosure via Set-Cookie caching in shared caches

Published 29 Sept 2026 · Updated 29 Sept 2026

Affected packages

Affected
>=7.0.0 <7.29.1
Fixed in
7.29.1
Update to the fixed version for your release line, for example:npm install undici@7.29.1
Affected
>=8.0.0 <8.10.2
Fixed in
8.10.2
Update to the fixed version for your release line, for example:npm install undici@8.10.2

Details

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.

Is GHSA-2jfj-6hjv-fm6j in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected undici, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.