Live › vulnerability › CVE-2026-106069
Go to dashboardNode.js normalizes a non-canonical IPv4 literal with a leading zero (such as 0127.0.0.1) differently in its certificate hostname check than the OS resolver does when connecting. A man-in-the-middle at the connected address can present a certificate issued for a different IP and be accepted as authentic.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that open TLS connections from Node.js 22.x, 24.x or 26.x to a host given as a non-canonical IPv4 literal with a leading zero, and that rely on certificate identity checks for that address. The sources do not say how common such literals are in real code, and clients that only use hostnames or canonical IP addresses are not described as affected.
No product ranges from the sources yet.
node --version and compare against the affected lines 22.x, 24.x and 26.xEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as 0127.0.0.1.
tls.checkServerIdentity() normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (0127.0.0.1 becomes 87.0.0.1), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (127.0.0.1). A server at the connected address can then be authenticated with a certificate issued for another IP address.
This vulnerability affects Node.js 26.x, 24.x, and 22.x.
This page as .md · .json · in your agent: get_signal("CVE-2026-106069")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.