CVE-2026-106072 in Node.js
Summary
by MITRE • 10/23/2026
A flaw in Node.js TLS hostname verification allows a certificate with only a DNS SAN to authenticate an IP endpoint 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 these hosts as IP addresses, but normalized them to their canonical form and matched the result against the certificate DNS names. A certificate containing `DNS:127.0.0.1` and no `IP Address:127.0.0.1` SAN was therefore accepted, while the same certificate is correctly rejected for `127.0.0.1`. Exploitation requires a certificate with a numeric DNS SAN issued by a CA trusted by the client, and a platform resolver that accepts these spellings, such as glibc.
This vulnerability affects Node.js **26.x**, **24.x**, and **22.x**.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The identified vulnerability represents a critical failure in hostname verification logic within the Transport Layer Security implementation of Node.js versions 26.x, 24.x, and 22.x. The core technical flaw resides in the tls.checkServerIdentity function, which is responsible for validating that the server's certificate matches the identity of the host it claims to be. Under normal circumstances, this process strictly distinguishes between DNS names and IP addresses, ensuring that certificates containing only Domain Name System Subject Alternative Names are not accepted when connecting via an IP address, and vice versa. However, in this specific scenario, the verification logic fails to correctly classify certain non-canonical IPv4 representations as IP addresses. Instead of rejecting them outright or treating them strictly as numeric identifiers, the function normalizes these unusual string formats into their canonical decimal dotted-decimal form before performing a comparison against the DNS names listed in the certificate's Subject Alternative Name extension. This logical error creates a bypass where an attacker can use a certificate issued for a specific IP address but labeled with that same value under the DNS type field, rather than the required IP Address SAN field, to successfully authenticate connections made using these non-standard IP notations.
The operational impact of this vulnerability is significant because it undermines the fundamental trust model established by Public Key Infrastructure and Certificate Authorities. An attacker who controls a domain or can obtain a certificate for an IP address via DNS-based validation methods could exploit this flaw if they can influence how the client resolves or formats the target host's address. By using non-canonical IPv4 spellings such as octal representations like 0177.0.0.1, hexadecimal forms like 0x7f.0.0.1, long integer conversions like 2130706433, or compact decimal notations like 127.1, an attacker can trick the Node.js runtime into accepting a certificate that should have been rejected due to missing IP Address SAN entries. This effectively allows for man-in-the-middle attacks where the client believes it is communicating with a legitimate server based on DNS validation rules, while actually connecting to an endpoint controlled by the adversary. The exploitation relies heavily on the underlying platform's resolver behavior; specifically, platforms like glibc that accept these non-standard IP address formats during resolution are susceptible to this attack vector. This means that any application running on such systems using affected Node.js versions is at risk of establishing encrypted sessions with unauthorized parties without raising standard certificate validation errors.
From a classification perspective, this vulnerability aligns closely with CWE-295 Improper Certificate Validation and CWE-613 Insufficient Session Expiration in HTTPS, as it involves the improper handling of identity verification mechanisms within secure transport protocols. In terms of the MITRE ATT&CK framework, this flaw facilitates techniques associated with Credential Access or Defense Evasion by allowing an attacker to bypass certificate pinning or strict hostname checks, thereby enabling interception of sensitive data transmitted over TLS connections. The severity is heightened because it affects widely used long-term support and current release branches of Node.js, impacting a vast ecosystem of server-side JavaScript applications that rely on secure communications for APIs, microservices, and database connectivity.
Mitigation strategies must address both the immediate software vulnerability and the broader environmental dependencies. For organizations running affected versions of Node.js, upgrading to a patched version is the primary remediation step. Developers should also audit their codebase for any direct usage of tls.checkServerIdentity or custom hostname verification logic that might replicate this normalization behavior. Additionally, since the exploitation depends on the platform resolver accepting non-canonical IP addresses, administrators can mitigate risk by configuring network stacks and resolvers to reject such ambiguous address formats where possible, although this may impact legacy application compatibility. It is also advisable to enforce strict certificate policies at the infrastructure level, ensuring that certificates intended for IP-based services explicitly include IP Address SANs rather than relying on DNS SANs, thereby reducing the attack surface even if software patches are delayed. Regular security audits and penetration testing should specifically target TLS handshake behaviors using non-standard address formats to detect similar implementation flaws in other components of the technology stack.