CVE-2026-42790
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk27th percentile - higher than 27% of all known CVEs
Summary
A vulnerability in the Erlang OTP public_key library allows bypassing DNS nameConstraints via subject CommonName fallback in TLS hostname verification. Two flaws enable a subordinate CA with restricted DNS nameConstraints to issue a leaf certificate accepted for an out-of-scope hostname.
Risk Assessment
The organization is at risk of man-in-the-middle attacks where an attacker can use a certificate from a restricted subordinate CA to impersonate any domain, potentially leading to interception of sensitive data.
Recommendation
Immediately update Erlang OTP to versions 29.0.1, 28.5.0.1, 27.3.4.12, or 26.2.5.21 depending on the branch used, along with the corresponding public_key library versions.
Other vulnerabilities in Erlang OTP public_key
See all- CVE-2026-59251High
A resource allocation vulnerability in Erlang/OTP's public_key certificate path validation allows a remote unauthenticated attacker to cause denial of service by sending a crafted X.509 certificate chain during TLS handshake. The certificate policy tree grows without bounds, exhausting BEAM schedulers and node memory, crashing the entire VM. This affects all TLS connections that validate peer certificates by default.
- CVE-2026-42789Medium
A vulnerability in the Erlang OTP public_key library (pubkey_cert module) allows improper following of a certificate's chain of trust. A non-CA certificate with basicConstraints cA:false and no keyUsage extension is incorrectly accepted as an intermediate issuer, enabling certificate chain forgery. Affected OTP versions: 17.0 through 29.0.1, 28.5.0.1, 27.3.4.12, and 26.2.5.21.
Original NVD description (English source)
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.