CVE-2026-42790

Published: Mag 27, 2026 Last Modified: Mag 27, 2026

ExploitDB:

Other exploit source:

Google Dorks:

HIGH 7,6

Source: 6b3ad84c-e1a6-4bf7-a703-f496b71e49db

Attack Vector: network

Attack Complexity: high

Privileges Required: none

User Interaction: passive

Confidentiality: N/A

Integrity: N/A

Availability: N/A

Description

AI Translation Available

Improper Certificate Validation vulnerability in Erlang OTP public_key (pubkey_cert and public_key modules) allows a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification.

Two flaws combine to allow a subordinate CA whose DNS nameConstraints are restricted (e.g. permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client accepts as a valid identity for an out-of-scope hostname (e.g. victim.example.com):

First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl only checks SAN DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree only restricts certificates that contain a DNS-typed name. A leaf with no subjectAltName therefore trivially satisfies any permitted;DNS:... constraint regardless of its subject commonName.

Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to the subject commonName when no subjectAltName is present, extracting id-at-commonName attributes as presented IDs and matching them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback.

The result is that path validation accepts a CN-only leaf under a DNS-constrained intermediate (no SAN means the nameConstraints are not triggered), and hostname verification then accepts it via the CN fallback. The bypass is reachable from stock ssl:connect with verify_peer, a trusted CA, SNI, and the canonical strict https hostname matcher.

This issue affects OTP from OTP 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

AI Generated Translation

Vulnerabilità di Improper Certificate Validation in Erlang OTP public_key (moduli pubkey_cert e public_key) consente un bypass dei DNS nameConstraints tramite fallback del CommonName del subject nella verifica del hostname TLS.

Due difetti combinati permettono a una CA subordinata, i cui DNS nameConstraints sono restrittivi (ad esempio, permitted;DNS:allowed.example.com), di emettere un certificato foglia che un client TLS OTP accetta come identità valida per un hostname fuori dal scope (ad esempio, victim.example.com):

In primo luogo, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl verifica solo le entry SAN DNS rispetto ai nameConstraints. Secondo RFC 5280, un sottoalbero DNS consentito limita solo i certificati che contengono un nome di tipo DNS. Un certificato foglia senza subjectAltName soddisfa quindi trivialmente qualsiasi constraint;DNS:... consentita, indipendentemente dal suo subject commonName.

In secondo luogo, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl ricorre al subject commonName quando non è presente un subjectAltName, estraendo gli attributi id-at-commonName come ID presentati e confrontandoli con l'hostname di riferimento. Il matcher strict pkix_verify_hostname_match_fun(https) non sopprime questo fallback.

Il risultato è che la validazione del percorso accetta un certificato foglia con CN solo sotto un intermediario con DNS-constrained (nessun SAN significa che i nameConstraints non vengono attivati), e la verifica del hostname lo accetta tramite il fallback al CN. Il bypass è raggiungibile con ssl:connect di default con verify_peer, CA trusted, SNI e il matcher hostname https strettamente canonico.

Questo problema riguarda OTP dalla versione OTP 19.3 fino a OTP 26.2.5.21, 27.3.4.12, 28.5.0.1 e 29.0.1, corrispondenti a public_key dalla versione 1.4 prima di 1.15.1.7, 1.17.1.3, 1.20.3.1 e 1.21.1.