undici's BalancedPool constructor passes its entire options object through an internal deep-clone that…

CVE-2026-84961 affects undici's BalancedPool class in versions 7.24.1 through 7.29.0 and 8.0.0 through 8.10.1. The constructor passes its options object through an internal deep-clone that uses JSON serialization. Because JSON.stringify cannot represent functions, any caller-supplied connect or tls option containing a checkServerIdentity callback, a custom ca certificate chain expressed via a function reference, or similar non-serializable TLS settings is silently dropped before reaching the TLS layer. The connection then falls back to Node.js's default Mozilla CA trust store, accepting certificates that the application explicitly intended to reject.

The vendor rated this HIGH (7.4) with AC:H, which is honest about the MITM prerequisite but overstates the real-world blast radius. The bug only fires when three conditions align simultaneously: the app uses BalancedPool specifically (not Pool, Client, or Agent), it passes function-valued TLS options, *and* an attacker holds a man-in-the-middle position. The intersection of those three conditions in production is narrow. Most undici consumers use fetch(), request(), or plain Pool — none of which route through the broken clone path. The vendor severity is fair for the theoretical ceiling but oversells the practical risk for typical Node.js deployments.

Why this verdict

• Narrow affected surface: Only BalancedPool with function-valued connect/tls options is affected. The dominant undici usage patterns (fetch(), request(), Pool, Client, Agent) are unaffected. This shrinks the vulnerable population to a small percentage of the 150M+ weekly install base.
• MITM prerequisite (AC:H): Exploiting this requires an active man-in-the-middle position on production server-to-server traffic. In cloud-native deployments (the dominant undici environment), this means compromising VPC networking or provider backbone — a high bar that implies the attacker already has significant access.
• No exploitation evidence: No in-the-wild exploitation, no public PoC, no KEV listing. The vulnerability was disclosed responsibly with patches available same-day. The theoretical attack is well-understood but has not been demonstrated.
• Role multiplier: undici's BalancedPool *could* be used in high-value roles (API gateways, service mesh proxies, CI/CD pipeline HTTP clients). In these roles, a successful MITM could expose secrets or enable supply-chain injection. However, (a) BalancedPool with custom TLS pinning is an uncommon pattern even in these roles, and (b) the MITM prerequisite means the attacker is already inside the network. The worst plausible high-value outcome is per-connection data interception, not fleet compromise or domain takeover — blast radius is connection-scoped, not host- or domain-scoped. This does not trigger the HIGH floor.
• Silent failure mode is concerning: The callback is dropped *silently* with no error or warning logged, which means affected applications have no indication their TLS validation is ineffective. This is the primary reason the verdict remains MEDIUM rather than LOW.

Why not higher?

The vendor's HIGH rating assumes the attacker can achieve MITM and the target uses the exact affected code path. In practice, the intersection of BalancedPool usage, custom TLS callbacks, and attainable MITM position is narrow. The blast radius is limited to specific connections within one application — there is no lateral movement, privilege escalation, or fleet-scale impact from this vulnerability alone. No high-value role deployment pattern triggers the HIGH floor because the outcome is connection-scoped interception, not domain or fleet compromise.

Why not lower?

The silent failure mode is genuinely dangerous for the applications that *do* use this pattern. Certificate pinning and custom CA validation are security controls deployed specifically in high-sensitivity contexts (financial APIs, healthcare data exchanges, zero-trust microservices). Silently removing those controls without any error undermines the application's security assumptions in exactly the scenarios where TLS validation matters most. The absence of any runtime warning makes detection difficult without explicit version auditing.

1. Switch from BalancedPool to Pool or Agent for TLS-pinned connections — The vulnerability only affects BalancedPool. Replacing it with Pool (single origin) or Agent (automatic connection management) preserves your custom TLS callbacks. This is the fastest mitigation — deploy within the noisgate MEDIUM remediation window of 365 days, though earlier is better if you have confirmed BalancedPool + custom TLS in your codebase.
2. Audit your codebase for BalancedPool + function-valued TLS options — Search for new BalancedPool in your Node.js projects and check whether the options object contains checkServerIdentity, ca as a function, or other non-serializable TLS properties. If none are found, this CVE does not affect you.
3. Pin undici version in package-lock.json and upgrade to 7.29.1 or 8.10.2 — The patch is available. Run npm audit fix or explicitly update undici. Verify with npm ls undici that no transitive dependency pulls in a vulnerable version.
4. Enable Certificate Transparency monitoring for your domains — If your application relies on certificate pinning, CT monitoring (crt.sh, Google CT) provides a detection layer for unexpected certificate issuance that would be needed for exploitation.

Run this on any host where your Node.js application is deployed or in your CI pipeline. Execute with bash check_cve_2026_84961.sh /path/to/your/project. No special privileges required — it reads node_modules and package-lock.json.

#!/usr/bin/env bash
# check_cve_2026_84961.sh — Detect undici versions vulnerable to CVE-2026-84961
# Usage: bash check_cve_2026_84961.sh [/path/to/project]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

PROJECT_DIR="${1:-.}"
VULNERABLE=0

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

# Find all installed undici versions
find "$PROJECT_DIR/node_modules" -path '*/undici/package.json' -not -path '*/node_modules/.cache/*' | while read -r pkg; do
  version=$(grep -o '"version": *"[^"]*"' "$pkg" | head -1 | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*')
  if [ -z "$version" ]; then
    continue
  fi
  major=$(echo "$version" | cut -d. -f1)
  minor=$(echo "$version" | cut -d. -f2)
  patch=$(echo "$version" | cut -d. -f3)

  vuln="no"
  # Check 7.24.1 through 7.29.0
  if [ "$major" -eq 7 ]; then
    if [ "$minor" -gt 24 ] && [ "$minor" -lt 29 ]; then
      vuln="yes"
    elif [ "$minor" -eq 24 ] && [ "$patch" -ge 1 ]; then
      vuln="yes"
    elif [ "$minor" -eq 29 ] && [ "$patch" -eq 0 ]; then
      vuln="yes"
    fi
  fi
  # Check 8.0.0 through 8.10.1
  if [ "$major" -eq 8 ]; then
    if [ "$minor" -lt 10 ]; then
      vuln="yes"
    elif [ "$minor" -eq 10 ] && [ "$patch" -le 1 ]; then
      vuln="yes"
    fi
  fi

  if [ "$vuln" = "yes" ]; then
    echo "VULNERABLE — undici $version found at $pkg"
    exit 1
  else
    echo "PATCHED — undici $version found at $pkg"
  fi
done

# If the loop didn't exit, check if undici was found at all
if ! find "$PROJECT_DIR/node_modules" -path '*/undici/package.json' -not -path '*/node_modules/.cache/*' | grep -q .; then
  echo "UNKNOWN — undici not found in $PROJECT_DIR"
  exit 2
fi

exit 0

Sources

1. GitHub Advisory GHSA-w293-vg96-wgc3
2. undici Releases — nodejs/undici
3. undici on npm
4. Snyk — undici package security
5. Socket.dev — undici security analysis
6. SecurityOnline — Four undici Vulnerabilities
7. FIRST EPSS FAQ