GHSA-2jfj-6hjv-fm6j: Infoleak
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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 8.10.2 - Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 7.29.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 7.29.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 8.10.2 - Configuration
Use a private cache (type: 'private') for per-user responses.
undici shared-cache interceptor type = private - Configuration
Strip Set-Cookie from responses before caching, or avoid caching responses that set cookies.
shared cache Set-Cookie handling = strip before caching
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using undici's cache interceptor in shared-cache mode against untrusted or multi-user upstreams are affected. Shared-cache mode is the default when using the interceptor; private caches are not affected.
What must an attacker or affected response do to trigger the issue?
A response that is cacheable, such as one with Cache-Control: public and a max-age value, must include a Set-Cookie header and be stored under a cache key later used by another caller. An untrusted upstream can use this to inject cookies that are then served to subsequent callers.
What can be done before upgrading?
Use type: 'private' for per-user responses, avoid caching responses that set cookies, or strip Set-Cookie headers before caching when operating as a shared cache. Upgrade to undici 7.29.1 or 8.10.2 when possible.
How can I determine whether cached callers may have been affected?
Review whether the application uses interceptors.cache() with its default shared mode and whether it cached responses containing Set-Cookie headers. Previously cached entries and revalidation paths are relevant because the vulnerable behavior could re-serve stored cookies to later callers.