undici's cache interceptor mishandles optional whitespace placed around the equals sign of a qualified…

CVE-2026-14643 is a parsing flaw in undici's cache interceptor — a feature introduced in v7 that is not enabled by default. When the interceptor is explicitly activated in *shared* cache mode, it fails to strip optional whitespace around the = sign in qualified Cache-Control directives like private=" authorization" or no-cache="\tauthorization". Because the padded field name no longer matches the literal string authorization, undici incorrectly classifies the response as fully cacheable. A subsequent unauthenticated caller whose request maps to the same cache key can then receive the first user's authenticated response body. Affected version ranges are undici 7.0.0 – 7.27.x and 8.0.0 – 8.4.x; fixes ship in 7.28.0 and 8.5.0.

The vendor's MEDIUM / 5.9 score is *generous* relative to real-world exploitability. The CVSS vector's AC:H acknowledges difficulty, but even that undersells the friction: three independent opt-in conditions must align — the developer must enable interceptors.cache(), set type: 'shared', and the upstream server must already emit non-canonical whitespace-padded directives that the attacker cannot control. No proof-of-concept code is public, no in-the-wild exploitation has been observed, and the vulnerability is not KEV-listed. The real-world population of deployments meeting all three conditions is vanishingly small, making the practical risk significantly lower than a network-reachable 5.9 suggests.

Why this verdict

• Triple opt-in chain compresses exploitable population to near zero. Three independent developer decisions — enabling the cache interceptor, selecting shared mode, and forwarding Authorization headers — must all be true simultaneously. Each is a minority configuration; their intersection is vanishingly small.
• Attacker cannot control the critical prerequisite. The whitespace-padded Cache-Control directive must originate from the upstream server. The attacker has no mechanism to inject or modify upstream response headers, making this a passive, opportunistic flaw rather than an actively weaponizable one.
• No exploitation evidence, no PoC, no KEV listing. The CVE was disclosed <48 hours ago with no public exploit code. The attack complexity is genuinely high even by the vendor's own assessment (AC:H), and real-world conditions make it harder still.
• Role multiplier: undici is a general-purpose HTTP client library. The cache interceptor in shared mode is not a canonically high-value-role component (it is not an IdP, DC, hypervisor, backup system, kernel-mode agent, or network edge appliance). In theory, a Node.js-based API gateway using shared caching could leak authenticated data between users (tenant-level blast radius), but this represents <0.1% of the installed base. The high-value-role floor does not apply because the fraction of installs occupying that role is far below the 1% threshold.
• Impact ceiling is confidentiality-only. Even in a worst-case scenario, the attacker obtains cached response bodies — no code execution, no persistence, no integrity compromise, no availability impact. Blast radius is limited to responses sharing a single cache key.

Why not higher?

The vendor's MEDIUM (5.9) already accounts for high attack complexity, but it does not adequately penalize the three independent opt-in conditions, the attacker's inability to control the upstream header, and the near-zero real-world exposure. Upgrading to MEDIUM or higher would require either active exploitation evidence, a public PoC lowering the bar, or data showing meaningful adoption of shared-mode caching — none of which exist.

Why not lower?

An IGNORE verdict would be inappropriate because the *mechanism* is real: if the conditions align, authenticated data genuinely leaks between users with no privilege required. The fix is a simple version bump, and defenders should still track it in their dependency hygiene backlog rather than pretend it doesn't exist.

1. Add Vary: Authorization on upstream origins — If the upstream response includes Vary: Authorization, the cache key incorporates the Authorization header value and responses are never shared across users. This is the single most effective server-side mitigation and should be verified on all origins serving authenticated content. No mitigation SLA applies at LOW severity — treat as backlog hygiene.
2. Switch cache interceptor to private mode — Change interceptors.cache({ type: 'shared' }) to interceptors.cache({ type: 'private' }) or omit the type parameter entirely (default is private). Private caches are scoped to a single user context and are not affected by this vulnerability.
3. Disable cache interceptor for authenticated traffic — If shared caching is required for performance, configure the interceptor to bypass caching when the outbound request includes an Authorization header. This eliminates the information-disclosure vector entirely.
4. Upgrade undici to ≥7.28.0 or ≥8.5.0 — The definitive fix. The patched versions correctly strip optional whitespace from qualified private and no-cache field names before comparison. At LOW severity, apply within the 365-day noisgate remediation window during your next dependency update cycle.

Run this on each application host (or in CI) where your Node.js services are deployed. It checks undici's installed version and greps for shared-mode cache interceptor usage. No special privileges needed — any user who can read node_modules and the application source. Example: bash check_cve_2026_14643.sh /opt/myapp

#!/usr/bin/env bash
# check_cve_2026_14643.sh — Detect undici cache interceptor whitespace bypass
# Usage: bash check_cve_2026_14643.sh <app_root_directory>
# Exit codes: 0 = PATCHED/NOT_AFFECTED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

APP_DIR="${1:-.}"

if [ ! -d "$APP_DIR" ]; then
  echo "UNKNOWN — directory $APP_DIR does not exist"
  exit 2
fi

# --- Step 1: Find undici version ---
PKG_JSON="$APP_DIR/node_modules/undici/package.json"
if [ ! -f "$PKG_JSON" ]; then
  echo "PATCHED — undici not installed (or not in node_modules); not affected"
  exit 0
fi

VERSION=$(node -e "console.log(require('$PKG_JSON').version)" 2>/dev/null || echo "")
if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not read undici version"
  exit 2
fi

echo "[*] undici version detected: $VERSION"

# --- Step 2: Check version range ---
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)

VULN_VERSION=false
if [ "$MAJOR" -eq 7 ] && [ "$MINOR" -lt 28 ]; then
  VULN_VERSION=true
elif [ "$MAJOR" -eq 8 ] && [ "$MINOR" -lt 5 ]; then
  VULN_VERSION=true
fi

if [ "$VULN_VERSION" = false ]; then
  echo "PATCHED — undici $VERSION is not in the affected range (7.0.0-7.27.x / 8.0.0-8.4.x)"
  exit 0
fi

echo "[!] undici $VERSION is in the affected range"

# --- Step 3: Check if shared-mode cache interceptor is used in source ---
echo "[*] Scanning source for interceptors.cache() in shared mode..."
if grep -rn --include='*.js' --include='*.ts' --include='*.mjs' --include='*.cjs' \
   -E 'interceptors\.cache|cache.*shared|type.*shared' "$APP_DIR/src" "$APP_DIR/lib" "$APP_DIR/app" "$APP_DIR/server" 2>/dev/null | \
   grep -qi 'shared'; then
  echo "VULNERABLE — undici $VERSION with shared-mode cache interceptor detected in source"
  exit 1
else
  echo "PATCHED — undici $VERSION is in the affected range but no shared-mode cache interceptor usage found in source (check manually if source is elsewhere)"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-pr7r-676h-xcf6
2. GitLab Advisory Database — undici
3. SecurityOnline — Four undici Vulnerabilities (133M Downloads)
4. undici on npm — version history
5. Platformatic Blog — Bringing HTTP Caching to Node.js
6. undici GitHub repository
7. Socket.dev — undici package analysis