Bug 2560613

Summary: CVE-2026-106072 nodejs24: nodejs: Authentication bypass via non-canonical IPv4 hostname verification [fedora-43]
Product: [Fedora] Fedora Reporter: Srikanth Balasubramanian <sbalasub>
Component: nodejs24Assignee: Jan Staněk <jstanek>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 43CC: aradchen, jstanek, tjuhasz
Target Milestone: ---Keywords: Security, SecurityTracking
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: {"flaws": ["822da0e2-24b2-4dac-928b-854bb7597f21"]}
Fixed In Version: nodejs24-24.22.1 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2026-11-03 11:26:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2560022    

Description Srikanth Balasubramanian 2026-10-26 11:45:05 UTC 
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

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**.
Comment 1 Jan Staněk 2026-11-03 11:26:40 UTC 
This vulnerability is fixed in the latest available release of nodejs24-24.22.1.