CVE-2026-106072
Description
A flaw was found in Node.js TLS hostname verification. When a client connects using a non-canonical IPv4 hostname spelling (for example 0177.0.0.1, 0x7f.0.0.1, 2130706433, or 127.1), tls.checkServerIdentity() may fail to classify the host as an IP address, normalize it to a canonical form, and match that form against certificate DNS SANs instead of requiring an IP Address SAN. A certificate that contains a DNS SAN equal to the canonical IP string (for example DNS:127.0.0.1) without a corresponding IP Address SAN can therefore be accepted for an IP endpoint. Exploitation requires a certificate with such a numeric DNS SAN that is trusted by the client, and a platform resolver that accepts the non-canonical spelling (glibc does).
Statement
This is a Moderate severity flaw, matching the upstream Node.js Medium rating. Red Hat aligns with the CNA CVSS (6.7): exploitation requires both a non-canonical IPv4 host form and a certificate with a DNS SAN for the canonical IP string that is already trusted by the client (Privileges Required: High relative to a generic network attacker without such a cert). On Red Hat platforms using glibc, the resolver accepts these spellings, so that part of the prerequisite is met. Successful abuse can confuse TLS endpoint identity with high confidentiality and integrity impact for the affected connection, but the trusted-cert barrier keeps the overall rating Moderate rather than Important.
Mitigation
Use only canonical IPv4 literals or DNS names in Node.js TLS client connect targets; reject octal, hex, dword, and shortened IPv4 spellings in application input.
Where feasible, pin expected server certificates or public keys for sensitive outbound TLS.
Restrict which destinations Node.js workloads may reach with egress controls.
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 | 6.7 | N/A | 6.7 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | High | N/A | High |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | Low | N/A | Low |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L
cve.org: CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L
Red Hat CVSS v3 Score Explanation
Aligned with upstream Node.js Medium rating and CNA vector. PR:H reflects that exploitation requires presenting a certificate with a numeric DNS SAN that the client already trusts (not a generic unauthenticated MitM). Distinct from high-severity CVE-2026-106069. glibc on RHEL accepts non-canonical IPv4 spellings.
Understanding the Weakness (CWE)
Integrity,Authentication
Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity
When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
