Log in Start free

Vulnerability · Published May 27, 2026 · Assigned by EEF

CVE-2026-42790nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification

High 7.4

In plain English

A high-severity improper certificate validation in OTP from Erlang. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.3% (higher than 28% of all known vulnerabilities). Fixed versions are available - upgrade the affected package.

Severity (CVSS 3.1)7.4High
Exploit odds (30 days)0.3%top 71.8% of all CVEs
Exploited in the wildNo reportsCISA SSVC: none
Attack toolingNoneno public tooling known

Official description

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 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12 and OTP 26.2.5.21, corresponding to public_key from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3 and 1.15.1.7.

Affected packages & fixed versions

EcosystemPackageFixed inAdvisory
Debian:12erlangno fix listedDEBIAN-CVE-2026-42790
Debian:13erlang1:27.3.4.1+dfsg-1+deb13u3DEBIAN-CVE-2026-42790
Debian:14erlang1:27.3.4.12+dfsg-1DEBIAN-CVE-2026-42790
Ubuntu:22.04:LTSerlang1:24.2.1+dfsg-1ubuntu0.8USN-8901-1
Ubuntu:22.04:LTSerlang1:24.2.1+dfsg-1ubuntu0.8UBUNTU-CVE-2026-42790
Ubuntu:24.04:LTSerlang1:25.3.2.8+dfsg-1ubuntu4.8USN-8901-1
Ubuntu:24.04:LTSerlang1:25.3.2.8+dfsg-1ubuntu4.8UBUNTU-CVE-2026-42790
Ubuntu:25.10erlangno fix listedUBUNTU-CVE-2026-42790
Ubuntu:26.04:LTSerlang1:27.3.4.6+dfsg-1ubuntu0.2UBUNTU-CVE-2026-42790
Ubuntu:26.04:LTSerlang1:27.3.4.6+dfsg-1ubuntu0.2USN-8901-1

Affected products (as reported)

VendorProductVersions
Erlang OTP 1.4 – before *
Erlang OTP 19.3 – before *b0c245e8132bb13171e277b1af59c0cec00c9459 – before *

Weakness: CWE-295, CWE-297 · Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

References