undici 8.10.0 omits the destination origin from the cache and request-deduplication keys when the cache or…

CVE-2026-85152 affects undici 8.10.0 and 8.10.1 only. When an application composes the interceptors.cache() or interceptors.deduplicate() interceptor with a dispatcher that handles requests to multiple origins, the destination origin is omitted from the cache and deduplication keys. This means two requests to *different* origins but with the same method, path, and qualifying headers will collide — an attacker-controlled origin's response can be served in place of a trusted origin's response. The chain can escalate to JWKS cache poisoning (accepting attacker-signed JWTs as if they came from a legitimate issuer) in applications that fetch signing keys from multiple issuers through the same undici dispatcher with caching enabled.

The vendor scored this HIGH 7.4 with AC:H already baked in, acknowledging the multi-origin dispatcher prerequisite. That's fair as a *theoretical ceiling*, but it overstates the risk for most enterprises. The cache and deduplicate interceptors are opt-in — they are not enabled by default and were introduced relatively recently in undici's interceptor API. The affected version window is razor-thin: only two minor releases (8.10.0, 8.10.1) before the fix in 8.10.2. No exploitation in the wild has been observed, no public PoC exists yet, and the CVE is not KEV-listed. For the vast majority of Node.js deployments that either don't use undici directly, don't use these interceptors, or aren't on the narrow affected range, this is noise.

Why this verdict

• Narrow version window: Only undici 8.10.0 and 8.10.1 are affected — released August 3 and ~September 1, 2026 respectively. Any organization not aggressively tracking undici minor releases is likely still on 8.9.x or 7.x and is unaffected.
• Opt-in interceptors: The interceptors.cache() and interceptors.deduplicate() APIs are not enabled by default. An application developer must explicitly compose them. This is a gating prerequisite that eliminates the majority of undici consumers.
• Multi-origin dispatcher prerequisite: The vulnerability only fires when a single dispatcher handles requests to ≥2 origins. Applications using per-origin Client or Pool instances (the common pattern for connection pooling) are not vulnerable.
• Role multiplier: undici is a general-purpose Node.js HTTP client library, not a canonically high-value-role component. *High-value scenario:* An API gateway or BFF service using undici's cache interceptor to fetch JWKS from multiple OIDC issuers — chain ends in token forgery (identity-tier blast radius). However, this requires the app to bypass dedicated JWKS libraries (get-jwks, jose) in favor of raw undici cache, which is architecturally unusual. Estimated <0.5% of the affected-version installed base occupies this role. The floor test does not trigger because the high-value role share is well below the 1% threshold.
• No exploitation signal: Zero in-the-wild activity, no PoC, no KEV listing. The CVSS AC:H already penalizes complexity but does not capture the opt-in and version-range friction.

Why not higher?

Upgrading to HIGH would require either evidence of active exploitation, a broader affected version range, or the interceptors being enabled by default. None of these conditions are met. The JWKS-poisoning chain, while theoretically severe, demands an unusual architectural stack that most Node.js applications don't use — the realistic blast radius for typical deployments is cross-origin data leakage in a backend service, not fleet-wide identity compromise.

Why not lower?

The vulnerability is network-reachable with no authentication required (PR:N), and the theoretical impact on confidentiality and integrity is genuinely high when the chain lands. A PoC could emerge quickly given the straightforward mechanics (cache key missing a field), and JWKS-poisoning scenarios — however unlikely — have outsized downstream consequences. Dropping below MEDIUM would understate the risk for the small population that IS exposed.

1. Pin or upgrade undici to 8.10.2+ — The definitive fix. Run npm audit fix or npm install [email protected] in affected projects. This adds the destination origin to cache and deduplication keys. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window, though the trivial fix cost justifies doing it this week.
2. Use per-origin dispatchers — If you cannot upgrade immediately, ensure each upstream origin gets its own Pool or Client instance rather than sharing a single Agent across origins. This prevents cross-origin key collisions regardless of the bug. Review your undici dispatcher topology.
3. Disable cache/deduplicate interceptors temporarily — If the interceptors are not performance-critical, remove interceptors.cache() and interceptors.deduplicate() from your dispatcher composition until you upgrade. This eliminates the vulnerability at the cost of increased upstream request volume.
4. Audit SBOM for undici 8.10.0–8.10.1 — Run npm ls undici across all Node.js services to identify which projects transitively depend on the affected versions. Prioritize services that act as API gateways, BFFs, or OIDC/JWKS consumers.

Run this on any host or CI runner with Node.js and npm/npx available. No special privileges required. Invoke: bash check_cve_2026_85152.sh /path/to/project where the argument is the root of a Node.js project with a node_modules directory.

#!/usr/bin/env bash
# check_cve_2026_85152.sh — Detect undici versions affected by CVE-2026-85152
# Usage: bash check_cve_2026_85152.sh /path/to/node/project
# Exit codes: 0 = PATCHED/not present, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"

if [ ! -d "$PROJECT_DIR/node_modules" ]; then
  echo "UNKNOWN — no node_modules found in $PROJECT_DIR"
  exit 2
fi

# Find all installed undici versions
VULN_FOUND=0
while IFS= read -r pkg_json; do
  version=$(node -e "try { console.log(require('$pkg_json').version) } catch(e) { console.log('') }" 2>/dev/null || true)
  if [ -z "$version" ]; then
    continue
  fi
  case "$version" in
    8.10.0|8.10.1)
      echo "VULNERABLE — undici $version found at $pkg_json"
      VULN_FOUND=1
      ;;
    *)
      echo "PATCHED — undici $version found at $pkg_json (not affected)"
      ;;
  esac
done < <(find "$PROJECT_DIR/node_modules" -path '*/undici/package.json' -not -path '*/node_modules/*/node_modules/*' 2>/dev/null)

if [ "$VULN_FOUND" -eq 1 ]; then
  exit 1
fi

# Check if undici was found at all
if ! find "$PROJECT_DIR/node_modules" -path '*/undici/package.json' -print -quit 2>/dev/null | grep -q .; then
  echo "PATCHED — undici not installed in this project"
fi

exit 0

Sources

1. GitHub Security Advisory GHSA-vp8m-p9jh-q5pm
2. undici GitHub Releases
3. undici npm package
4. undici Security Advisories (GitLab GLAD)
5. Snyk — undici security vulnerabilities
6. stack.watch — undici 2026 vulnerabilities
7. Node.js undici repository