HighGHSA-qrxm-fqhp-jwvmCVE-2026-87018

undici vulnerable to Denial of Service via TLS 1.2 certificate-changing renegotiation

Published 27 Oct 2026 · Updated 27 Oct 2026

Affected packages

Affected
>=4.2.1 <6.29.1
Fixed in
6.29.1
Update to the fixed version for your release line, for example:npm install undici@6.29.1
Affected
>=7.0.0 <7.30.1
Fixed in
7.30.1
Update to the fixed version for your release line, for example:npm install undici@7.30.1
Affected
>=8.0.0 <8.12.2
Fixed in
8.12.2
Update to the fixed version for your release line, for example:npm install undici@8.12.2

Details

Impact

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.

Patches

Upgrade to undici 6.29.1, 7.30.1, or 8.12.2.

Workarounds

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.

Is GHSA-qrxm-fqhp-jwvm in any of your client repos?

Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected undici, and gives you the command that fixes it.

References

Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.