CVE-2026-42790: CWE-295 Improper Certificate Validation in Erlang OTP
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.
AI Analysis
Technical Summary
The vulnerability arises from two combined flaws in Erlang OTP's public_key module: first, the function pubkey_cert:validate_names/6 only checks DNS entries in the SAN against nameConstraints, ignoring the CN field when SAN is absent; second, public_key:pkix_verify_hostname/3 falls back to the CN for hostname verification if no SAN is present. This allows a subordinate CA restricted by DNS nameConstraints to issue a leaf certificate lacking SAN but with a malicious CN, which an Erlang OTP TLS client accepts as valid for an out-of-scope hostname. This improper certificate validation can lead to hostname spoofing and man-in-the-middle attacks.
Potential Impact
An attacker controlling a subordinate CA can bypass DNS nameConstraints restrictions and issue certificates that appear valid for hostnames outside the permitted scope. This can lead to hostname spoofing and man-in-the-middle attacks, compromising the integrity and confidentiality of TLS communications in Erlang OTP clients. The vulnerability affects the trust model of TLS connections relying on Erlang OTP's public_key module for certificate validation.
Mitigation Recommendations
A fix is available and should be applied. Vendors including Red Hat have released patched versions addressing this issue. As an immediate mitigation, ensure all TLS certificates include Subject Alternative Name (SAN) extensions with appropriate DNS entries, avoiding reliance on the CommonName (CN) field for hostname verification. Erlang applications can configure the ssl module's verify_fun option to reject peer certificates missing the subjectAltName extension. Users should apply vendor patches promptly and follow vendor-specific update instructions.
CVE-2026-42790: CWE-295 Improper Certificate Validation in Erlang OTP
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.
CVSS v4.0
Score 7.6high
Affected software
Erlang
OTP
Erlang
OTP
cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:*Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises from two combined flaws in Erlang OTP's public_key module: first, the function pubkey_cert:validate_names/6 only checks DNS entries in the SAN against nameConstraints, ignoring the CN field when SAN is absent; second, public_key:pkix_verify_hostname/3 falls back to the CN for hostname verification if no SAN is present. This allows a subordinate CA restricted by DNS nameConstraints to issue a leaf certificate lacking SAN but with a malicious CN, which an Erlang OTP TLS client accepts as valid for an out-of-scope hostname. This improper certificate validation can lead to hostname spoofing and man-in-the-middle attacks.
Potential Impact
An attacker controlling a subordinate CA can bypass DNS nameConstraints restrictions and issue certificates that appear valid for hostnames outside the permitted scope. This can lead to hostname spoofing and man-in-the-middle attacks, compromising the integrity and confidentiality of TLS communications in Erlang OTP clients. The vulnerability affects the trust model of TLS connections relying on Erlang OTP's public_key module for certificate validation.
Mitigation Recommendations
A fix is available and should be applied. Vendors including Red Hat have released patched versions addressing this issue. As an immediate mitigation, ensure all TLS certificates include Subject Alternative Name (SAN) extensions with appropriate DNS entries, avoiding reliance on the CommonName (CN) field for hostname verification. Erlang applications can configure the ssl module's verify_fun option to reject peer certificates missing the subjectAltName extension. Users should apply vendor patches promptly and follow vendor-specific update instructions.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-04-29T18:06:33.251Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Is Cloud Service
- true
- Vendor Advisory Urls
- [{"url":"https://access.redhat.com/security/cve/CVE-2026-42790","vendor":"Red Hat"}]
Threat ID: 6a171ce4e29bf47b50d1de32
Added to database: 05/27/2026, 16:33:40 UTC
Last enriched: 08/14/2026, 13:09:27 UTC
Last updated: 09/13/2026, 01:44:08 UTC
Views: 80
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.