undici vulnerable to cross-user information disclosure via shared cache whitespace bypass
Published 18 Jun 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=7.0.0 <7.28.0
- Fixed in
- 7.28.0
npm install undici@7.28.0- Affected
- >=8.0.0 <8.5.0
- Fixed in
- 8.5.0
npm install undici@8.5.0Details
Impact
Undici's cache interceptor incorrectly classifies some responses as cacheable when the upstream Cache-Control header uses whitespace-padded qualified private or no-cache field names such as private=" authorization" or no-cache="\tauthorization". The parser preserves the surrounding whitespace, so later comparisons against the literal authorization field name fail and the response is stored.
In shared-cache mode, this allows a response containing one user's authenticated data to be served from cache to a subsequent caller, including an unauthenticated caller, when both requests resolve to the same cache key.
Affected applications are those that explicitly enable the cache interceptor (interceptors.cache()) in shared mode, forward Authorization headers upstream, and receive cacheable responses with non-canonical qualified private or no-cache directives.
Patches
Upgrade to undici v7.28.0 or v8.5.0.
Workarounds
If upgrade is not immediately possible, disable shared-cache mode for traffic that includes Authorization headers, avoid caching responses to authenticated requests, or add Vary: Authorization upstream.
Is GHSA-pr7r-676h-xcf6 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.