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).
Déclaration
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.
Mesure d'atténuation
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.
Détails du score du système commun d'évaluation des vulnérabilités (CVSS)
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).
Répartition des scores CVSS v3
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Score de base | 6.7 | N/A | 6.7 |
| Vecteur d'attaque | Network | N/A | Network |
| Complexité de l'attaque | Low | N/A | Low |
| Privilèges requis | High | N/A | High |
| Interaction avec l'utilisateur | None | N/A | None |
| Champ d'application | Unchanged | N/A | Unchanged |
| Confidentialité | High | N/A | High |
| Impact sur l'intégrité | High | N/A | High |
| Impact sur la disponibilité | Low | N/A | Low |
Vecteur
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
Explication du score CVSS v3 de Red Hat
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.
Comprendre la Défaillance (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.
Questions fréquemment posées
Not sure what something means? Check out our Security Glossary.
Vous souhaitez recevoir des notifications d'errata ? Signez ici.
