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 c
- Published
- Last modified
- Status
- published
- Known exploitation
- Not listed in CISA KEV
- Public exploit
- None on Exploit-DB
Summary
The vulnerability affects Node.js versions 22.x, 24.x, and 26.x, specifically its TLS hostname verification used when clients connect to servers using non-canonical IPv4 addresses with leading zeros. This can allow a client to accept a server certificate issued for a different IP address than the one it actually connected to, potentially enabling a malicious server to impersonate another trusted host.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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**.
Affected versions
- nodejs node
From 22.23.3 · through 22.23.3; From 24.22.0 · through 24.22.0; From 26.12.0 · through 26.12.0