CVE-2026-106069
Description
A flaw was found in the Node.js TLS stack. When a non-canonical numeric hostname is used, hostname normalization for certificate verification can disagree with how the platform resolves the address used for the connection. This can cause checkServerIdentity to accept a certificate that does not identify the peer that was actually connected, allowing server impersonation.
Statement
This issue is rated Important. Exploitation requires a Node.js TLS client to connect using a non-canonical numeric hostname that normalizes to an IP address for certificate matching while name resolution uses a different interpretation, and a certificate that includes an IP subjectAltName matching the normalized address. Attack Complexity is High due to these prerequisites and the need to influence the connection target or traffic. Confidentiality and Integrity are High for a successful impersonation of a TLS peer; Availability is not affected. Upstream rates this High and fixed it in Node.js 22.23.4, 24.22.1, and 26.12.1.
Mitigation
To mitigate, reject non-canonical numeric hostnames before opening TLS connections. Restrict outbound TLS to trusted destinations only, and isolate services that make TLS client connections based on untrusted input.
--- CME Mitigation Guidance (2026-11-02) ---
Disclaimer: The following mitigation solutions are provided as a courtesy, pending the application of an official patch. This content was generated utilizing AI tools in conjunction with data from https://cmetaxonomy.org. Customers are advised to independently evaluate and test these temporary mitigations within their own infrastructure.
The highest-value action is to validate and canonicalize numeric hostnames prior to TLS client connection setup to eliminate normalization discrepancies against the platform resolver: upgrade to Node.js 22.23.4, 24.22.1, 26.12.1 (or the fixed Nodejs/Nodejs:22/Nodejs/Nodejs:24/Nodejs/Nodejs:26/Nodejs/Cloudservices/Subscription Central Automation builds), which reject non-canonical IP addresses during hostname verification, closing all 2 injection vectors (IPv4 literal with leading zero octal notation, abbreviated numeric IPv4 address format). Until patched, this is a concern on Node.js TLS client applications connecting to untrusted hostnames across supported platforms, so reject non-canonical numeric hostnames before initiating TLS connections, restrict outbound TLS requests to trusted destinations, and isolate client services handling untrusted connection targets. As a compensating measure, pin expected server certificates or public keys to reject unauthorized peer certificates even if hostname verification is deceived by address normalization differences. These controls limit blast radius and contain exploitation, but they do not fix the underlying hostname normalization discrepancy defect — apply the upstream patch to fully remediate.
Highest-impact CME: CME-1304 SSRF Prevention (Outbound Request Allowlist) (high)
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 7.4 | N/A | 7.4 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | High | N/A | High |
| Privileges Required | None | N/A | None |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
cve.org: CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Red Hat CVSS v3 Score Explanation
AC:H: requires a non-canonical numeric hostname, disagreement between certificate normalization and resolver behavior, and a certificate with a matching IP SAN. C/I:H for TLS peer impersonation; A:N. Rated Important (7.4).
Understanding the Weakness (CWE)
Access Control
Technical Impact: Gain Privileges or Assume Identity
The data read from the system vouched for by the certificate may not be from the expected system.
Authentication,Other
Technical Impact: Other
Trust afforded to the system in question - based on the malicious certificate - may allow for spoofing or redirection attacks.
Access Control,Other
Technical Impact: Gain Privileges or Assume Identity; Other
If the certificate's host-specific data is not properly checked - such as the Common Name (CN) in the Subject or the Subject Alternative Name (SAN) extension of an X.509 certificate - it may be possible for a redirection or spoofing attack to allow a malicious host with a valid certificate to provide data, impersonating a trusted host.
Acknowledgements
Upstream acknowledges anagnorisis2peripeteia as the original reporter.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
