A flaw in Node.js TLS hostname verification allows a client to accept a certificate that claims to cover a domain name such as DNS:127.0.0.1 or DNS:*.0.0.1 even when the hostname in the connection string is an IPv4 address written with non‑ASCII characters (for example, fullwidth digits). The underlying bug in tls.checkServerIdentity() fails to recognise such hostnames as IP addresses, normalises them to the regular IPv4 address, and then compares the DNS name or Common Name in the certificate instead of the IP address itself. Because of this, an attacker can present a certificate that is not intended for a particular IP address and have the connection accepted, effectively impersonating the server intended for that IP. The weakness falls under CWE‑295, indicating improper transport layer security configuration.

Node.js 26.x and 24.x versions are affected by this regression, which was introduced after the fix for CVE-2026-48618. The vulnerability applies to programs that use Node.js’s native TLS library and invoke the default hostname verification routine.

The CVSS base score of 7.4 indicates a high severity, while the EPSS score is currently unavailable, so the exact exploitation probability is unknown. The vulnerability is not listed in CISA’s KEV catalog, but the impact remains significant because any application that performs TLS connections with hostnames containing non‑ASCII characters can be tricked into accepting a mis‑issued certificate. The likely attack vector involves an attacker controlling the server side to supply a certificate that includes DNS:127.0.0.1 or DNS:*.0.0.1, or compromising a legitimate server that has such a certificate, then presenting that server to a Node.js client that uses a hostname with non‑ASCII digits.