Loading vulnerability details...
Two issues in undici's cache interceptor, both fixed by the same patch on lib/util/cache.js:
Cache-Control: private directives such as private="" or private="," can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.private directives in the same header (such as public, max-age=60, private, private="hdr") cause an uncaught TypeError in the cache-control parser, terminating the request.Applications using interceptors.cache() in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including Set-Cookie.
Required conditions:
Cache-Control: public, max-age=300, private="";Vary header.Applications using interceptors.cache() against an upstream that returns a Cache-Control header combining unqualified private with qualified private="..." see an uncaught TypeError: output.private.concat is not a function during response handling. The request rejects; depending on the consumer's error handling, the process may exit.
private="" is parsed as { private: [''] }. The shared-cache guard only rejects private === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.
For the crash variant, an unqualified private directive sets output.private = true, then a subsequent qualified private="hdr" directive attempts output.private.concat(['hdr']), which throws because boolean has no concat method.
The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to true and preserves existing true values, closing both vectors.
Upgrade to undici 7.29.0 or 8.9.0. Both releases fix the qualified private directive handling that caused the shared-cache storage and the parser crash.
Until patched, avoid shared interceptors.cache() for user-specific responses, use type: 'private', or disable caching for affected origins.
Disclosure variant reported by @h0rk1p via HackerOne report #3817497.
Two issues in undici's cache interceptor, both fixed by the same patch on lib/util/cache.js:
Cache-Control: private directives such as private="" or private="," can be incorrectly stored in the default shared cache, then served to a later caller with the same cache key.private directives in the same header (such as public, max-age=60, private, private="hdr") cause an uncaught TypeError in the cache-control parser, terminating the request.Applications using interceptors.cache() in shared mode may cache a user-specific response and serve it to a later caller with the same cache key. This can disclose private response bodies and headers, including Set-Cookie.
Required conditions:
Cache-Control: public, max-age=300, private="";Vary header.Applications using interceptors.cache() against an upstream that returns a Cache-Control header combining unqualified private with qualified private="..." see an uncaught TypeError: output.private.concat is not a function during response handling. The request rejects; depending on the consumer's error handling, the process may exit.
private="" is parsed as { private: [''] }. The shared-cache guard only rejects private === true, so the response can be stored. When served from cache, the previous user's body and headers may be returned to a different user.
For the crash variant, an unqualified private directive sets output.private = true, then a subsequent qualified private="hdr" directive attempts output.private.concat(['hdr']), which throws because boolean has no concat method.
The patch routes the qualified-directive path through a shared helper that normalizes empty-after-trim arrays to true and preserves existing true values, closing both vectors.
Upgrade to undici 7.29.0 or 8.9.0. Both releases fix the qualified private directive handling that caused the shared-cache storage and the parser crash.
Until patched, avoid shared interceptors.cache() for user-specific responses, use type: 'private', or disable caching for affected origins.
Disclosure variant reported by @h0rk1p via HackerOne report #3817497. This vulnerability involves weaknesses in
This high-severity vulnerability could allow attackers to gain unauthorized access, execute arbitrary code, or compromise data integrity. Prompt remediation is strongly recommended.
Probability of exploitation in the next 30 days · more likely than 45.8% of all CVEs.
Apply security patches to version 7.29.0, 8.9.0 immediately
Isolate affected systems from untrusted networks until patching is complete
Implement enhanced monitoring for exploitation attempts and unusual behavior