CVE-2026-106072

What it actually does

Node.js tls.checkServerIdentity() fails to classify non-canonical IPv4 notations (0177.0.0.1, 0x7f.0.0.1, 2130706433, 127.1) as IP addresses, instead normalizing them and matching against DNS SANs; a certificate bearing only DNS:127.0.0.1 is therefore accepted for an IP connection that should require an IP Address SAN.

Why it matters to the business

Organizations running Node.js 22.x, 24.x or 26.x face elevated risk of TLS man-in-the-middle or unauthorized endpoint impersonation on IP-based services until patches are applied; low EPSS and absence from KEV indicate limited observed exploitation but the four-day-old flaw and rising EPSS trend warrant prompt attention given Node.js prevalence.

How an attack unfolds

An attacker obtains a publicly trusted certificate containing only a DNS SAN for the target IP address, then causes a vulnerable Node.js client to connect using a non-canonical IPv4 spelling accepted by the platform resolver (e.g., glibc); the flawed check normalizes the address and matches the DNS SAN, allowing the attacker-controlled endpoint to complete the TLS handshake.

How to fix it

Upgrade Node.js 22.x, 24.x and 26.x installations to the first patched releases containing the corrected tls.checkServerIdentity() logic as soon as they become available; until then restrict outbound TLS connections to canonical IP literals or enforce certificate pinning that requires explicit IP Address SANs.

How to confirm the fix worked

After upgrade, run Node.js unit tests exercising tls.checkServerIdentity() with both canonical and non-canonical IPv4 forms against certificates containing only DNS SANs; confirm that non-canonical forms now correctly require an IP Address SAN and are rejected when absent.

Typical attack path

1. Acquire CA-issued certificate listing only a DNS SAN for the target IP
2. Position MitM or malicious server reachable via the non-canonical IPv4 notation
3. Trigger Node.js client connection using that notation
4. tls.checkServerIdentity() incorrectly accepts the certificate
5. TLS session established with attacker-controlled endpoint

How to detect it

Search application and TLS library logs for outbound connections that record non-canonical IPv4 literals in the servername or host field; correlate with certificate validation events that succeed against certificates whose SANs contain only DNS names matching the normalized IP.

What your security team should do

• Inventory all Node.js 22.x/24.x/26.x deployments and prioritize patching within 30 days
• Monitor EPSS trend and any new exploit code for the next 14 days
• Add runtime checks or proxies that normalize IP addresses before TLS handshakes where feasible
• Review certificate issuance policies to require IP Address SANs for any IP endpoints