CVE-2026-9678

What it actually does

CVE-2026-9678 is an information disclosure flaw in Undici’s cache interceptor. When applications explicitly enable `interceptors.cache()` in shared-cache mode, Undici may incorrectly treat some authenticated upstream responses as cacheable if the `Cache-Control` header contains whitespace-padded qualified `private` or `no-cache` field names, such as `private=" authorization"` or `no-cache="\tauthorization"`. Because the parser preserves the whitespace, later checks fail to match the protected `authorization` field name, allowing a response associated with an `Authorization` header to be stored and later served to another request with the same cache key. The issue can expose one user’s authenticated response body or headers to another user, including an unauthenticated caller, depending on application routing, cache key construction, and upstream cache-control behavior.

Why it matters to the business

Affected applications may unintentionally disclose authenticated user data through an application-level HTTP cache. The main business risk is confidentiality loss: personal data, account details, API responses, or other sensitive information returned to one user could be shown to another user. Exploitation requires a specific configuration and upstream response pattern, so broad internet-wide exploitation is less likely than for a simple remote code execution issue; however, the impact can still be significant for services handling regulated, customer, financial, health, or internal business data. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no reported mature public exploitation, but any exposed shared-cache deployment that forwards `Authorization` headers should be treated as a priority confidentiality risk.

How an attack unfolds

An attacker targets an application that uses Node.js Undici with the cache interceptor enabled in shared mode. The application forwards `Authorization` headers to an upstream service and uses a cache key that does not sufficiently separate authenticated users. The upstream service returns a response with `Cache-Control` directives intended to prevent authorization-derived content from being shared, but the directive uses a qualified field name with leading whitespace, such as `private=" authorization"` or `no-cache="\tauthorization"`. Due to Undici’s parsing behavior, the interceptor fails to recognize that the `authorization` field should prevent shared caching and stores the response. The attacker then makes a later request that maps to the same cache key. If the cache entry is still valid, Undici serves the previously cached authenticated response to the attacker, potentially revealing another user’s sensitive data without requiring the attacker to compromise credentials or execute code.

How to fix it

Upgrade Undici to a patched version: `undici` v7.28.0 or later in the 7.x line, or v8.5.0 or later in the 8.x line. If Undici is pulled transitively, update the direct dependency that brings it in and verify the resolved lockfile version. If immediate upgrade is not possible, disable `interceptors.cache()` shared-cache mode for any traffic that includes `Authorization` headers, avoid caching responses to authenticated requests, ensure cache keys include the relevant authentication context where caching is unavoidable, and configure upstream services to send `Vary: Authorization`. Also normalize or reject malformed/ambiguous `Cache-Control` qualified field names at the application or proxy layer where feasible. Review cache policies for all authenticated HTTP flows, not only the endpoint where Undici is directly used.

How to confirm the fix worked

Confirm that the deployed dependency tree resolves to `undici` v7.28.0 or later, or v8.5.0 or later. Use package manager tooling such as `npm ls undici`, `pnpm why undici`, or `yarn why undici`, and inspect lockfiles and built artifacts for older versions. Review code for use of `interceptors.cache()` and determine whether it is configured in shared-cache mode. Validate that authenticated outbound requests are not stored in a shared cache by testing responses containing headers such as `Cache-Control: private=" authorization"` and `Cache-Control: no-cache="\tauthorization"`; after an authenticated request, repeat the same cache-key-equivalent request without credentials or with different credentials and verify that the prior user’s response is not returned. Confirm upstream responses include appropriate `Vary: Authorization` or equivalent cache-separation controls for authenticated resources.

Typical attack path

1. Identify a Node.js application or service path likely using Undici caching behavior for outbound HTTP requests.
2. Find an endpoint where requests with `Authorization` headers are forwarded upstream and where multiple callers can resolve to the same cache key.
3. Cause or wait for a victim request that receives a response with a whitespace-padded qualified `Cache-Control` directive such as `private=" authorization"` or `no-cache="\tauthorization"`.
4. Allow the vulnerable shared cache interceptor to incorrectly store the authenticated response.
5. Send a subsequent unauthenticated or differently authenticated request that resolves to the same cache key.
6. Receive the cached response containing data that should have been limited to the original authenticated caller.

How to detect it

To determine whether exploitation or accidental disclosure occurred, focus on application access logs, upstream service logs, cache interceptor telemetry if available, API gateway logs, and authentication/authorization logs. Look for sequences where an authenticated request to a cacheable resource is followed by an unauthenticated or differently authenticated request to the same method, URL, query string, and effective cache key, with the later request receiving the same response size, ETag, cache status, request identifier, or body fingerprint. Review responses from upstream services for `Cache-Control` headers containing qualified `private` or `no-cache` field names with leading spaces, tabs, or other whitespace before `authorization`. Investigate any cache hits for requests lacking `Authorization` that occur after cache stores for requests containing `Authorization`. If response-body logging or DLP telemetry exists, compare user identifiers or account identifiers in response content against the authenticated principal that received the response. There are no universal malware-style indicators for this vulnerability; detection depends heavily on HTTP request/response logs, cache-hit metadata, and application-specific evidence of cross-user data exposure.

• interceptors.cache()
• Cache-Control: private=" authorization"
• Cache-Control: private="\tauthorization"
• Cache-Control: no-cache=" authorization"
• Cache-Control: no-cache="\tauthorization"
• Authorization
• Vary: Authorization
• undici@7.27
• undici@7.27.0
• undici@8.4
• undici@8.4.0

What your security team should do

• Inventory Node.js applications and services that use Undici directly or transitively, prioritizing externally reachable services and services that handle sensitive authenticated data.
• Upgrade affected deployments to `undici` v7.28.0 or v8.5.0 or later, and verify the resolved runtime version rather than only the declared package version.
• Search application code and configuration for `interceptors.cache()` and prioritize any use of shared-cache mode with forwarded `Authorization` headers.
• Temporarily disable shared caching for authenticated traffic if patching cannot be completed immediately.
• Review upstream cache-control behavior for authenticated endpoints and add `Vary: Authorization` where appropriate.
• Add regression tests ensuring authenticated responses cannot be served to unauthenticated or differently authenticated callers sharing the same URL or cache key.
• Monitor logs for suspicious repeated requests to the same resource where an unauthenticated or different user receives a response shortly after an authenticated request.
• Because this is not currently KEV-listed, has low EPSS, and has no known exploit maturity, prioritize based on data sensitivity and confirmed vulnerable configuration rather than CVSS alone.