CVE-2026-106072

Overview

Node.js is an asynchronous, event-driven JavaScript runtime designed for building scalable network applications. Its tls module, which https and other TLS clients build on, verifies that the server's certificate was issued for the host the client connected to. tls.checkServerIdentity() checks an IP address host against the certificate's IP Address entries and a host name against its DNS names, using the URL parser's domainToASCII() to normalize the host first.

An improper certificate validation vulnerability (CVE-2026-106072) has been identified in Node.js's TLS hostname verification. A certificate that names 127.0.0.1 only as a DNS name is supposed to be rejected for a connection to the IP address 127.0.0.1, and Node.js does reject it when the host is written that way. However, when the client connects using a non-canonical IPv4 spelling such as 0177.0.0.1, 0x7f.0.0.1, 2130706433 or 127.1, tls.checkServerIdentity() did not classify the host as an IP address. It normalized the host to its canonical form and matched the result against the certificate's DNS names, so a certificate containing DNS:127.0.0.1 and no IP Address:127.0.0.1 entry was accepted for the IP endpoint.

This behaviour maps to CWE-295 (Improper Certificate Validation), the weakness assigned in the CVE record, where the product does not validate, or incorrectly validates, a certificate. In Node.js, whether a certificate is accepted for an IP endpoint depends on how the address is spelled, and a DNS name entry is allowed to stand in for an IP Address entry.

Exploitation requires a certificate with a numeric DNS name issued by a CA the client trusts, a client that connects to one of these spellings (for example from a URL or address taken from input), and a platform resolver that accepts the spelling, such as glibc. Clients that connect to host names or to canonical dotted-decimal addresses are not exposed. The Node.js project describes the issue as affecting its supported 22.x, 24.x and 26.x lines. The upstream End-of-Life lines do not contain the affected code: they compare the host with the certificate exactly as written. The HeroDevs NES v22 line carries the upstream normalization and is affected in the same way as upstream 22.x.

Details

Module Info

• Product: Node.js
• Affected packages: node (built-in tls module; lib/tls.js)
• Affected versions: >=22.0.0 <22.23.4, >=24.0.0 <24.22.1, >=26.0.0 <26.12.1
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://nodejs.org/en/download
• Package manager: Not applicable; Node.js is distributed as runtime builds from nodejs.org rather than as a published npm package
• Fixed in: Node.js 22.23.4, 24.22.1, and 26.12.1; Node.js NES v22.23.5

Vulnerability Info

This Medium-severity vulnerability is found in tls.checkServerIdentity() in Node.js's tls module (lib/tls.js). The HackerOne CNA scores it 6.7 (CVSS v3.0) and the Node.js project rates it Medium; NVD has not yet scored it.

The function is supposed to send every IP address host to the IP Address check. In the vulnerable implementation, the decision is made by net.isIP() on the host as written, while DNS-name matching uses the normalized host.

net.isIP() recognizes only canonical dotted-decimal IPv4, so it returns 0 for octal (0177.0.0.1), hexadecimal (0x7f.0.0.1), single-number (2130706433) and shortened (127.1) forms. domainToASCII() follows the WHATWG URL rules, which parse all four as the IPv4 address 127.0.0.1. The host therefore reaches the DNS-name branch as 127.0.0.1 and matches a DNS:127.0.0.1 entry. A resolver such as glibc reads the same spellings as 127.0.0.1 too, so the client connects to that address and accepts a certificate that does not list it as an IP address.

Note: On 22.x releases up to 22.23.3, tls.checkServerIdentity() decides whether the host is an IP address from the normalized form, so these spellings are checked against IP Address entries rather than DNS names. The 22.x line has the same fix in 22.23.4, which rejects these spellings outright.

Mitigation

Node.js 22.x, 24.x and 26.x are supported and are fixed in 22.23.4, 24.22.1 and 26.12.1 and later. The upstream End-of-Life release lines do not contain the affected code and need no upgrade for this issue. For more information on End-of-Life release lines see the Node.js previous releases schedule.

Users of the affected components should apply one of the following mitigations:

• Upgrade to Node.js 22.23.4, 24.22.1 or 26.12.1 or later on those lines, all of which include this fix.
• Migrate affected applications away from the End-of-Life Node.js release lines.
• Leverage a commercial support partner like HeroDevs for post-EOL security support, through Node.js NES.

Credits

• br41ny (reporter)
• Matteo Collina (remediation developer)