undici's cache interceptor mishandles malformed Cache-Control private directives

CVE-2026-13697 affects undici's cache interceptor, introduced in v7. When an upstream origin server sends a Cache-Control header with whitespace-padded qualified field names — e.g. private=" authorization" or no-cache="\tauthorization" — the parser preserves the surrounding whitespace. The subsequent string comparison against the literal authorization token fails, so undici incorrectly classifies the response as cacheable. In shared-cache mode, a response containing one user's authenticated data can then be served from cache to a different caller, including an unauthenticated one, when both requests resolve to the same cache key. Affected versions are 7.0.0 through 7.27.x and 8.0.0 through 8.4.x; fixes land in 7.28.0 and 8.5.0.

The vendor rates this HIGH at 7.4, but that overstates the real-world risk by a full severity tier. The cache interceptor is not enabled by default — developers must explicitly call interceptors.cache() to activate it. Even among those who do, the vulnerability further requires the origin server to emit non-standard whitespace-padded Cache-Control directives, which is rare in production. The vendor's CVSS vector also includes A:H (Availability: High), but the documented mechanism is a cache-logic parsing error that produces information disclosure, not service disruption. The earlier GHSA-pr7r-676h-xcf6 advisory for the closely related CVE-2026-9678 scored the same class of bug at 5.9 MODERATE with A:N, which better reflects the actual impact.

Why this verdict

• Opt-in feature narrows population: The cache interceptor must be explicitly enabled via interceptors.cache() — it is not active by default. This alone eliminates the vast majority of undici's 125M+ weekly download base from the vulnerable population. Downward pressure: significant.
• Non-standard origin behavior required (AC:H): Exploitation requires the upstream origin server to independently send malformed whitespace-padded Cache-Control field names like private=" authorization". This is non-standard and rare in production environments. The attacker cannot cause this condition without a separate header-injection bug. Downward pressure: significant.
• No exploitation evidence: No PoC, no KEV listing, no in-the-wild campaigns observed. EPSS for the related CVE-2026-9678 is approximately 0.64%. Downward pressure: moderate.
• Availability impact overrated: The vendor vector includes A:H, but the documented vulnerability mechanism — whitespace in Cache-Control parsing causing incorrect caching — produces *information disclosure*, not service disruption. The GHSA for the same class of bug used A:N (CVSS 5.9). Adjusting A:H to A:N alone would drop the score from 7.4 to 5.9. Downward pressure: moderate.
• Role multiplier: undici is a client-side HTTP library embedded in Node.js backends. In an API gateway or BFF role, the chain could succeed and leak user-to-user data at the *application/tenant* scope — not fleet, domain, or supply-chain scope. undici is not canonically a high-value-role component (it is not a hypervisor, IdP, PAM, backup server, CA, or network edge device). The blast radius does not meet the floor threshold for HIGH because compromise is bounded to one application's user base, not infrastructure-wide takeover.

Why not higher?

No known exploitation in the wild, no PoC code, and no KEV listing. The attack requires two independent, unusual preconditions (opt-in cache explicitly enabled AND malformed origin headers) — making real-world exploitation unlikely without a targeted campaign against a known vulnerable service. The blast radius is application-tenant scoped, not infrastructure-wide.

Why not lower?

When the preconditions ARE met, the impact is genuine cross-user data leakage with no authentication required from the attacker (PR:N, AV:N). undici's massive install base means even a small opt-in percentage translates to thousands of potentially affected services. The confidentiality impact (C:H) is real and could expose PII, session tokens, or API keys cached from another user's response.

1. Switch cache interceptor to private mode for authenticated routes — Change interceptors.cache({ type: 'private' }) or disable the cache entirely for routes that forward Authorization headers. This eliminates the cross-user leak vector regardless of origin header formatting. Apply within the noisgate MEDIUM remediation window (365 days), though sooner is better for services handling sensitive data.
2. Add Vary: Authorization on origin servers — Configure upstream origins to include Vary: Authorization in responses. This forces cache keys to differ per Authorization header value, preventing cross-user cache hits even if the response is incorrectly classified as cacheable. This is a server-side change, not an undici change.
3. Upgrade undici to >=7.28.0 or >=8.5.0 — The definitive fix. Run npm update undici or pin the patched version in package.json. For applications using Node.js core fetch, check whether your Node.js release bundles an updated undici. Target within the 365-day noisgate remediation SLA.
4. Exclude authenticated requests from cache interceptor — If you cannot upgrade immediately, add application logic to bypass the cache interceptor for any request carrying an Authorization header. This prevents sensitive responses from entering the shared cache at all.

Run this script from the root directory of any Node.js project on the target host. It checks the installed undici version against the affected ranges. Requires node on PATH; no elevated privileges needed. Example: bash check_cve_2026_13697.sh /opt/myapp

#!/usr/bin/env bash
# noisgate CVE-2026-13697 checker
# Detects vulnerable undici versions (cache interceptor whitespace bypass)
# Run from a Node.js project root. No elevated privileges needed.
# Usage: bash check_cve_2026_13697.sh [/path/to/project]
set -euo pipefail
DIR=${1:-.}
if [ ! -d "$DIR" ]; then
  echo "UNKNOWN - directory not found"; exit 2
fi
cd "$DIR"
VER=
if [ -f node_modules/undici/package.json ]; then
  VER=$(node -p 'require("./node_modules/undici/package.json").version' 2>/dev/null || true)
fi
if [ -z "$VER" ] && command -v npm &>/dev/null && [ -f package.json ]; then
  VER=$(npm ls undici --depth=0 2>/dev/null | grep -oE 'undici@[0-9]+\.[0-9]+\.[0-9]+' | head -1 | cut -d@ -f2 || true)
fi
if [ -z "$VER" ]; then
  echo "UNKNOWN - undici not detected"; exit 2
fi
IFS=. read -r MAJ MIN PAT <<< "$VER"
if [ "$MAJ" -lt 7 ]; then
  echo "PATCHED - undici $VER predates cache interceptor (not affected)"; exit 0
elif [ "$MAJ" -eq 7 ] && [ "$MIN" -lt 28 ]; then
  echo "VULNERABLE - undici $VER (fix: >=7.28.0)"; exit 1
elif [ "$MAJ" -eq 8 ] && [ "$MIN" -lt 5 ]; then
  echo "VULNERABLE - undici $VER (fix: >=8.5.0)"; exit 1
else
  echo "PATCHED - undici $VER"; exit 0
fi

Sources

1. GitHub Security Advisory GHSA-pr7r-676h-xcf6
2. SecurityOnline — Four undici Vulnerabilities (133M Weekly Downloads)
3. NVD — CVE-2026-9678 (related cache interceptor CVE)
4. undici releases on GitHub
5. Platformatic — Bringing HTTP Caching to Node.js
6. npm trends — undici download statistics
7. OpenJS Foundation CNA — Security Advisories