CVE-2026-9678: Undici Cache Interceptor Data Leakage via Whitespace Padding

Technical summary

The vulnerability stems from a whitespace-handling defect in undici's cache interceptor qualification parser. When evaluating Cache-Control field-values in private or no-cache directives, the parser preserves leading and trailing whitespace around the field name (e.g., `no-cache="\tauthorization"` becomes a quoted token that includes the tab character). Subsequent literal string comparisons against the unpadded field name 'authorization' fail, causing the directive to be ineffective. In shared-cache mode, responses that should be marked as uncacheable or private are instead cached and reused across cache keys that resolve to the same entry, violating cache segregation when Authorization headers are involved. The root cause is improper canonicalization of qualified directives before comparison, allowing non-canonical variants to bypass cache control logic. Affected versions are those prior to 7.28.0 and 8.5.0.

Business impact

Organizations relying on undici's shared-cache mode for API clients, reverse proxies, or gateway patterns face a confidentiality breach risk: authenticated user data embedded in cacheable responses can leak to other users or anonymous callers. In multi-tenant SaaS environments, horizontal pod autoscaling scenarios, or any deployment where a single cache instance services requests from different principals, this vulnerability could expose personalized information, API tokens, or session credentials. The impact is particularly acute in serverless or containerized architectures where cache instances are frequently reused. Compliance implications include potential violations of data segregation controls (HIPAA, PCI-DSS, GDPR) if customer or cardholder data is inadvertently shared. The attack requires no authentication and relies on predictable cache key collisions, making detection and attribution difficult.

Affected systems

Directly affected are applications using the Node.js undici library versions prior to 7.28.0 or 8.5.0 that: (1) explicitly instantiate the cache interceptor via `interceptors.cache()`, (2) operate that cache in shared mode (rather than private), (3) forward Authorization headers in upstream requests, and (4) interact with upstream servers that emit Cache-Control directives with whitespace-padded field names. Less common but possible: custom HTTP middleware or proxies built on undici, containerized API gateways, and Node.js-based load balancers or reverse proxies. Applications using undici without enabling the cache interceptor, or using it only in private-cache mode, are not affected. Applications that do not forward Authorization headers are also not at risk.

Exploitability

Exploitability is moderate and requires specific preconditions: an attacker must either control (or influence) the upstream server's Cache-Control response headers to inject whitespace-padded directives, or wait for a legitimate misconfiguration to occur upstream. No special privileges, credentials, or unusual user interaction are required. The attack is passive from the attacker's perspective—once a malformed directive causes a cached response to be stored, any subsequent request matching that cache key will retrieve the exposed data. In managed cloud environments where third-party APIs or CDNs are used, this risk is elevated because upstream server behavior is not under the application operator's direct control. Detection is difficult because the attack leaves minimal footprint; cache hits are not logged by default, and the malformed directive may appear innocuous in network logs.

Remediation

Upgrade undici to version 7.28.0 (for the 7.x line) or 8.5.0 (for the 8.x line) or later. For applications unable to patch immediately, implement one or more of the following mitigations: disable shared-cache mode when handling traffic containing Authorization headers and switch to private-cache mode; configure your application to not cache responses to authenticated requests (check for Authorization in request or Set-Cookie in response); add a Vary: Authorization response header requirement upstream so that cache keys incorporate authorization state. Additionally, audit upstream server configurations to ensure Cache-Control directives conform to RFC 7234 (no extraneous whitespace in field names).

Patch guidance

Verify your current undici version by checking package.json or running `npm list undici`. If you are on 7.x, upgrade to 7.28.0 or later via `npm install undici@^7.28.0`. If you are on 8.x, upgrade to 8.5.0 or later via `npm install undici@^8.5.0`. If you maintain applications that lock specific versions, review your dependency management policy and schedule patching within your standard security update cycle. Test in a staging environment, particularly focusing on cache behavior and authenticated requests. If you are on an older major version (6.x or earlier), consult the undici release notes and consider upgrading to a supported line; end-of-life versions should not remain in production.

Detection guidance

Enable request and response logging in your undici client or proxy to capture Cache-Control headers from upstream responses. Look for directives with atypical whitespace: `private="` `authorization"` or `no-cache="\tauthorization"`. Monitor cache hit rates for endpoints that receive Authorization headers—a sudden increase may indicate unintended cache reuse. If you have access to application logs, search for authenticated requests followed by unauthenticated requests that return identical or sensitive response bodies. In containerized environments, examine images for undici versions prior to 7.28.0 and 8.5.0. Implement cache inspection tooling (e.g., logging cache key generation and hit/miss events) if available through undici's diagnostic APIs. Note that the vulnerability does not trigger an exception or obvious error; normal cache operation will mask it.

Why prioritize this

CVE-2026-9678 warrants immediate attention for teams using undici in shared-cache configurations, but is not critical because it requires explicit enablement of the cache interceptor and relies on upstream server misconfiguration or attacker control of Cache-Control headers. The CVSS 3.1 score of 5.9 (MEDIUM) reflects the high confidentiality impact but moderate attack complexity. It is not on the CISA KEV list. Prioritization should focus on: (1) immediate patching of shared-cache deployments handling authenticated traffic, (2) inventory of which applications use undici and have the cache interceptor enabled, and (3) verification that upstream servers emit canonical Cache-Control directives. For pure private-cache or cache-disabled deployments, remediation can be scheduled in the next standard maintenance window but should not be deferred beyond 30 days.

Risk score, explained

The CVSS 3.1 score of 5.9 is derived from: network-accessible attack vector (AV:N), high attack complexity due to the need for either upstream misconfiguration or attacker control of headers (AC:H), no privilege requirements (PR:N), no user interaction (UI:N), unchanged scope (S:U), high confidentiality impact from potential exposure of authenticated user data (C:H), no integrity impact (I:N), and no availability impact (A:N). The score appropriately reflects that confidentiality is the primary concern—a breach of data isolation in caching—but the necessary preconditions (explicit cache enablement, shared mode, Authorization header forwarding, and malformed directives) prevent this from being scored higher. In the context of a data-sensitive workload (healthcare, finance, government), actual risk may exceed the base score.

Frequently asked questions