undici vulnerable to Denial of Service via unrequested WebSocket subprotocol

CVE-2026-19534 affects the undici HTTP/WebSocket client library bundled in Node.js 18+. When a Node.js application opens a WebSocket connection and the remote server responds with a Sec-WebSocket-Protocol header the client never requested, undici throws an uncaught TypeError in a microtask callback. Because the exception is unhandled, the entire Node.js process terminates immediately. The bug exists in undici versions 6.7.0–6.28.0, 7.0.0–7.29.0, and 8.0.0–8.10.1, and is fixed in 6.28.1, 7.29.1, and 8.10.2.

The vendor rates this HIGH at CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), and on paper the vector looks clean: network-reachable, no auth, no interaction. But the vector is misleading. This is a client-side vulnerability — the attacker must control the WebSocket server the victim connects to, or must man-in-the-middle a plaintext ws:// connection. In practice, this means the attacker cannot just send a packet to crash your service; your application must be making outbound WebSocket connections to an endpoint the attacker controls. That prerequisite dramatically narrows real-world exploitability. The availability-only impact (process crash, no code execution, no data exfiltration) further limits blast radius, especially since Node.js deployments typically run behind process managers that auto-restart.

Why this verdict

• Client-side inversion: The CVSS vector says AV:N/PR:N, implying an attacker can remotely crash your server. In reality, the attacker must *be* the server (or MITM plaintext ws://). Your application must dial out to the attacker. This is a fundamental narrowing that CVSS cannot express.
• WebSocket usage fraction: undici has 143M weekly npm downloads, but the vast majority use it as the HTTP fetch engine bundled in Node.js. The WebSocket client API is a niche feature — likely <5% of the installed base actively uses undici WebSocket connections to external servers.
• Availability-only, auto-recoverable: Impact is a process crash. No code execution, no memory disclosure, no data exfiltration. Modern Node.js deployments run under process managers (pm2, systemd, Kubernetes) that restart within seconds. Circuit breakers stop reconnect loops.
• Role multiplier: undici runs inside Node.js application processes. In *low-value roles* (frontend BFF, API gateway proxying HTTP), the WebSocket path is unused — chain does not start. In *typical roles* (backend service consuming a real-time data feed via WebSocket), a crash causes brief service disruption (host-level blast radius, auto-recovered). In *high-value roles* (CI/CD runners, SIEM integrations, monitoring agents using WebSocket), the chain could succeed if the upstream WebSocket endpoint is compromised, but the outcome is still a recoverable process crash — not domain takeover, not supply-chain pivot, not data breach. No high-value role produces a fleet-scale or identity-scale outcome, so the floor is not triggered.
• No exploitation evidence: No KEV listing, no known campaigns, no EPSS score, no weaponized tooling. The bug is conceptually simple but requires a specific and unusual attacker position.

Why not higher?

A HIGH rating would require either active exploitation evidence or a realistic attack path where an unauthenticated remote attacker can crash victim services at scale. Here, the attacker cannot initiate the connection — the victim must connect outbound to the attacker's server. This prerequisite eliminates the vast majority of Node.js deployments from the reachable population. The availability-only impact with automatic recovery further caps severity.

Why not lower?

A LOW rating would undercount the risk for the subset of applications that do make outbound WebSocket connections to semi-trusted or user-influenced endpoints (e.g., webhook relay services, multi-tenant integrations). In those scenarios, an attacker who compromises or impersonates a WebSocket endpoint can reliably crash the consuming service with a single handshake response, with no authentication required. The trivial exploit complexity within the reachable population keeps this above LOW.

1. Wrap WebSocket connections in global uncaught exception handlers — Add process.on('uncaughtException', handler) to catch the TypeError and log it instead of crashing. This is a stopgap — the connection will still fail, but the process survives. Deploy as a code change within the 365-day noisgate remediation SLA.
2. Enforce wss:// (TLS) for all outbound WebSocket connections — Eliminates the MITM vector entirely. If your WebSocket endpoints support TLS (they should), ensure no ws:// URLs remain in configuration. This does not protect against a compromised legitimate server but removes one attack path.
3. Use a WebSocket reconnect library with circuit breaker — Libraries like reconnecting-websocket with exponential backoff and max-retry limits prevent crash-restart loops from becoming a sustained DoS. The process still crashes once, but the loop breaks.
4. Pin outbound WebSocket endpoints to known-good servers — If your application connects to external WebSocket services, allowlist the endpoints. Do not allow user-supplied or dynamically resolved WebSocket URLs without validation.

Run this on any host where a Node.js application uses undici. It checks the installed undici version(s) against the vulnerable ranges. No special privileges required — just access to the project directory. Example: bash check_cve_2026_19534.sh /opt/myapp

#!/usr/bin/env bash
# check_cve_2026_19534.sh — Detect CVE-2026-19534 vulnerable undici versions
# Usage: bash check_cve_2026_19534.sh <project_directory>
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

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

check_version() {
  local ver="$1"
  local major minor patch
  IFS='.' read -r major minor patch <<< "$ver"
  major=${major:-0}; minor=${minor:-0}; patch=${patch:-0}

  if [[ $major -eq 6 ]] && [[ $minor -ge 7 ]]; then
    if [[ $minor -lt 28 ]] || { [[ $minor -eq 28 ]] && [[ $patch -lt 1 ]]; }; then
      return 1  # vulnerable
    fi
  fi
  if [[ $major -eq 7 ]]; then
    if [[ $minor -lt 29 ]] || { [[ $minor -eq 29 ]] && [[ $patch -lt 1 ]]; }; then
      return 1  # vulnerable
    fi
  fi
  if [[ $major -eq 8 ]]; then
    if [[ $minor -lt 10 ]] || { [[ $minor -eq 10 ]] && [[ $patch -lt 2 ]]; }; then
      return 1  # vulnerable
    fi
  fi
  return 0  # patched or unaffected
}

# Check npm-installed undici
if [ -f "$PROJECT_DIR/node_modules/undici/package.json" ]; then
  NPM_VER=$(node -e "console.log(require('$PROJECT_DIR/node_modules/undici/package.json').version)" 2>/dev/null || echo "")
  if [ -n "$NPM_VER" ]; then
    if check_version "$NPM_VER"; then
      echo "[PATCHED] npm undici $NPM_VER is not vulnerable."
    else
      echo "[VULNERABLE] npm undici $NPM_VER is affected by CVE-2026-19534."
      VULNERABLE=1
    fi
  fi
else
  echo "[INFO] No npm undici found in $PROJECT_DIR/node_modules."
fi

# Check Node.js bundled undici
BUNDLED_VER=$(node -e "console.log(process.versions.undici || '')" 2>/dev/null || echo "")
if [ -n "$BUNDLED_VER" ]; then
  if check_version "$BUNDLED_VER"; then
    echo "[PATCHED] Bundled undici $BUNDLED_VER is not vulnerable."
  else
    echo "[VULNERABLE] Node.js bundled undici $BUNDLED_VER is affected by CVE-2026-19534."
    VULNERABLE=1
  fi
else
  echo "[INFO] Could not detect bundled undici version (Node.js < 18?)."
fi

if [ $VULNERABLE -eq 1 ]; then
  echo "\nResult: VULNERABLE"
  exit 1
else
  echo "\nResult: PATCHED"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-rfgv-xxqx-mfg5
2. undici npm package
3. undici Security Advisories
4. Stack.watch undici 2026 vulnerabilities
5. CISA Known Exploited Vulnerabilities Catalog
6. FIRST EPSS API
7. RFC 6455 §4.1 — WebSocket Opening Handshake