Live › vulnerability › CVE-2026-87018
Go to dashboardundici, the HTTP client behind Node's global fetch, crashes the whole Node.js process when a TLS 1.2 server renegotiates the connection and presents a certificate whose hostname does not match. An attacker who controls or can impersonate the HTTPS endpoint can take down all in-flight requests and background work with one renegotiation.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 19:04 UTC, 0h before NVD. All times on this page are UTC.
Any Node.js application that uses undici directly or the global fetch() on a version in an affected range is exposed when it connects to an HTTPS endpoint that negotiates TLS 1.2. The attacker must control or be able to reach the endpoint and present a CA-trusted certificate for a different hostname; no CA compromise is needed. Services that only talk to TLS 1.3 endpoints, or that have already moved to a patched undici, can skip the urgent action.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| undici | npm | >= 4.2.1, < 6.29.1 | 6.29.1 |
| undici | npm | >= 7.0.0, < 7.30.1 | 7.30.1 |
| undici | npm | >= 8.0.0, < 8.12.2 | 8.12.2 |
| nodejs undici | vendor | >= 4.2.1, < 6.29.1 | 6.29.1 |
| nodejs undici | vendor | >= 7.0.0, < 7.30.1 | 7.30.1 |
| nodejs undici | vendor | >= 8.0.0, < 8.12.2 | 8.12.2 |
npm ls undici in each project and check whether the resolved version falls in the affected ranges: >= 4.2.1, < 6.29.1, >= 7.0.0, < 7.30.1, or >= 8.0.0, < 8.12.2.6.29.1, 7.30.1, or 8.12.2 depending on the major line in use.connect: { minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3' } on the client or agent, only where the target endpoints support TLS 1.3.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
undici crashes the client process when a TLS 1.2 server renegotiates after the connection is established and presents a different, CA-trusted certificate whose hostname does not match the requested host. Node.js re-runs hostname verification on the renegotiated handshake and destroys the socket with ERR_TLS_CERT_ALTNAME_INVALID. undici's established socket error handler asserted that this error code could never occur, so the peer-controlled error became an uncaught AssertionError that terminates the Node.js process. Both the HTTP/1.1 and HTTP/2 paths are affected.
A malicious or compromised HTTPS endpoint reached through undici or the global fetch() can crash the client with a single server-initiated renegotiation, taking down all in-flight requests and background work in the process. Only TLS 1.2 is affected, because TLS 1.3 does not support renegotiation. Exploitation does not require a CA compromise: the attacker controls the endpoint and can present two ordinary valid certificates, the first matching the requested URL and the second intentionally not matching it.
Upgrade to undici 6.29.1, 7.30.1, or 8.12.2.
Restrict outbound connections to TLS 1.3, for example by setting connect: { minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3' } on the client or agent, so that renegotiation cannot occur, when the target endpoints support TLS 1.3.
This page as .md · .json · in your agent: get_signal("CVE-2026-87018")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.