CVE-2026-87018: Node.js Undici TLS Renegotiation DoS Vulnerability

CVE-2026-87018 Overview

CVE-2026-87018 is a denial-of-service vulnerability in undici, the HTTP client library used by Node.js and the global fetch() API. The flaw affects versions 4.2.1 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1. A malicious or compromised HTTPS endpoint can crash the entire Node.js process by initiating a TLS 1.2 renegotiation and presenting a different CA-trusted certificate whose hostname does not match the original request. Node.js re-runs hostname verification and surfaces a certificate-altname error that undici incorrectly asserts can never occur, converting a peer-controlled error into an uncaught assertion [CWE-248].

Critical Impact
A single server-initiated TLS 1.2 renegotiation terminates the Node.js process, dropping all in-flight requests and background work.

Affected Products

undici 4.2.1 through 6.29.0
undici 7.0.0 through 7.30.0
undici 8.0.0 through 8.12.1 (including Node.js global fetch())

Discovery Timeline

2026-10-15 - CVE-2026-87018 published to NVD
2026-10-19 - Last updated in NVD database

Technical Details for CVE-2026-87018

Vulnerability Analysis

The vulnerability lies in undici's established-socket error handler. After a TLS connection is established, undici registers an error handler that asserts certain Node.js TLS error codes cannot propagate on an already-connected socket. One of those codes, ERR_TLS_CERT_ALTNAME_INVALID, is in fact reachable when a TLS 1.2 server renegotiates the handshake mid-connection and presents a new certificate that does not match the original request hostname.

When Node.js completes the renegotiated handshake, it re-runs hostname verification on the new certificate. If verification fails, Node.js destroys the socket with the altname error. undici receives that error path on a connection it considered validated, triggering an assertion failure that is not catchable from user code. Both the HTTP/1.1 and HTTP/2 request paths route through this handler, so applications using either protocol are affected.

Root Cause

The root cause is an overly strict invariant: the error handler assumed hostname-verification errors could only occur during the initial TLS handshake, not after. TLS 1.2 renegotiation breaks that assumption because it allows the server to swap certificates on an established session.

Attack Vector

An attacker controls an HTTPS endpoint that a target Node.js application contacts through undici or fetch(). The attacker presents a valid certificate for the requested hostname during the initial handshake, then triggers a TLS 1.2 renegotiation and presents a second, CA-trusted certificate for a different hostname. No certificate authority compromise is required because both certificates are legitimately issued. TLS 1.3 is not affected because the protocol removes renegotiation.

Detection Methods for CVE-2026-87018

Indicators of Compromise

Unexpected Node.js process termination accompanied by an AssertionError referencing undici in stderr or crash logs.
Error messages containing ERR_TLS_CERT_ALTNAME_INVALID originating from outbound HTTPS traffic.
Repeated TLS 1.2 renegotiation events observed in network telemetry toward Node.js clients.

Detection Strategies

Inventory Node.js services and resolve installed undici versions, including transitive dependencies pulled in by fetch(), using npm ls undici or software composition analysis.
Alert on process crashes where the exit reason includes an uncaught AssertionError from undici modules.
Inspect TLS session telemetry for renegotiation handshakes against clients, which are uncommon in modern deployments.

Monitoring Recommendations

Forward Node.js stderr and process-supervisor restart events to centralized logging for correlation.
Monitor egress TLS metadata for TLS 1.2 negotiations where TLS 1.3 is otherwise expected.
Track application availability metrics for sudden drops in in-flight request counts that align with upstream TLS errors.

How to Mitigate CVE-2026-87018

Immediate Actions Required

Upgrade undici to 6.29.1, 7.30.1, 8.12.2, or later across all Node.js services and container images.
Audit direct and transitive dependencies that bundle an older undici, including frameworks that wrap fetch().
Review outbound HTTPS destinations and restrict calls to trusted endpoints where feasible.

Patch Information

The maintainers fixed the issue in undici 6.29.1, 7.30.1, and 8.12.2. Patch details are documented in GitHub Advisory GHSA-qrxm-fqhp-jwvm and the OpenJS Foundation Security Advisories. Users should upgrade immediately; there is no backport required beyond selecting the matching major-version fix.

Workarounds

Restrict outbound TLS to version 1.3 for endpoints that support it, since TLS 1.3 does not permit renegotiation.
Set the minVersion option on undici Agent or Dispatcher TLS configuration to TLSv1.3 for controlled destinations.
Isolate HTTP client calls to child processes or workers so a crash from an untrusted endpoint does not take down the main service.

bash

# Upgrade undici to a patched release
npm install undici@^8.12.2

# Or pin to the fixed version in your major line
npm install undici@6.29.1
npm install undici@7.30.1