CVE-2026-106069

What it actually does

tls.checkServerIdentity() normalizes non-canonical IPv4 literals with leading-zero octets using WHATWG URL octal rules while the OS resolver uses decimal interpretation, allowing a certificate for one IP to be accepted for a connection to a different IP.

Why it matters to the business

Attackers can intercept TLS connections to IP-literal hosts on affected Node.js versions and impersonate servers, risking exposure of sensitive data or unauthorized access in environments that rely on IP-based certificate validation.

How an attack unfolds

An attacker positions a malicious server at a decimal IP address that matches the octal interpretation of a leading-zero literal; when a vulnerable client connects using that literal, the mismatched normalization allows the attacker's certificate to pass identity checks.

How to fix it

Upgrade all Node.js 22.x, 24.x, and 26.x installations to the latest patched releases that correct the normalization inconsistency in tls.checkServerIdentity(). Until upgrades are complete, avoid using non-canonical IPv4 literals with leading zeros for TLS hostnames and prefer DNS names or canonical decimal literals.

How to confirm the fix worked

Review Node.js release notes and changelogs for the specific fix commit addressing IPv4 literal normalization in checkServerIdentity(); test connections using literals such as 0127.0.0.1 against both vulnerable and patched versions to confirm correct rejection of mismatched certificates.

Typical attack path

1. Identify Node.js applications that connect to TLS endpoints using non-canonical IPv4 literals containing leading-zero octets.
2. Register or compromise a host reachable at the decimal interpretation of the literal.
3. Obtain or forge a TLS certificate valid for the octal-normalized address.
4. Intercept or redirect the client connection and present the certificate during the TLS handshake.
5. Bypass hostname verification and establish an authenticated TLS session to the attacker-controlled endpoint.

How to detect it

Search application and TLS library logs for outbound connections that specify IPv4 addresses containing octets with leading zeros; correlate with certificate validation events or errors around the time of the handshake.

What your security team should do

• Prioritize patching of Node.js 22.x, 24.x, and 26.x within the next 7 days given the recent publication and rising EPSS trend.
• Audit application code and configuration for any hardcoded or dynamically constructed IPv4 literals containing leading zeros.
• Implement additional TLS pinning or certificate transparency checks for high-value connections until patching is complete.
• Update dependency scanners and SBOM processes to flag vulnerable Node.js versions.