Bug 2482286 (CVE-2026-42790)

Summary: CVE-2026-42790 erlang: Erlang OTP public_key: Certificate validation bypass allows hostname spoofing
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: eglynn, jjoyce, jpretori, jschluet, lhh, mburns, mgarciac
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Erlang OTP public_key. This improper certificate validation vulnerability allows a subordinate Certificate Authority (CA) with restricted DNS nameConstraints to bypass these restrictions. By issuing a leaf certificate that lacks a Subject Alternative Name (SAN) but contains a crafted CommonName (CN), an attacker can trick an Erlang OTP TLS client into accepting it as valid for an out-of-scope hostname. This can lead to hostname spoofing and potential man-in-the-middle attacks, compromising the integrity and confidentiality of communications.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-05-27 17:03:16 UTC 
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.
Comment 2 errata-xmlrpc 2026-07-15 09:53:28 UTC 
This issue has been addressed in the following products:

  Red Hat OpenStack Services on OpenShift 18.0

Via RHSA-2026:39809 https://access.redhat.com/errata/RHSA-2026:39809