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 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 Analysis
Technical Summary
This vulnerability involves improper certificate validation in Erlang OTP's public_key modules (pubkey_cert and public_key). The validation logic only enforces DNS nameConstraints on subjectAltName DNS entries, ignoring the subject CommonName when no subjectAltName is present, per RFC 5280. Consequently, a subordinate CA constrained to a DNS subtree can issue a leaf certificate without subjectAltName that is accepted for hostnames outside the permitted DNS subtree due to fallback to the CommonName in hostname verification. This bypass affects OTP versions from 19.3 up to but not including 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1, corresponding to public_key versions before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1. The vulnerability is reachable using stock ssl:connect with verify_peer, trusted CA, SNI, and strict https hostname matcher.
Potential Impact
An attacker controlling a subordinate CA with DNS nameConstraints can issue a leaf certificate without subjectAltName that is accepted by Erlang OTP TLS clients for hostnames outside the permitted DNS subtree. This undermines TLS hostname verification, potentially allowing man-in-the-middle attacks or impersonation of unauthorized hostnames. The vulnerability affects TLS clients using vulnerable OTP versions and can lead to trust violations in secure communications.
Mitigation Recommendations
A patch is available for this vulnerability. The vendor manages remediation for this cloud-hosted service, so users of Erlang OTP cloud services should verify that their provider has applied the fix. For self-managed deployments, upgrade to OTP versions 26.2.5.21, 27.3.4.12, 28.5.0.1, 29.0.1 or later, or corresponding public_key module versions 1.15.1.7, 1.17.1.3, 1.20.3.1, 1.21.1 or later. Check the vendor advisory for the latest remediation guidance.
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 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.
CVSS v4.0
Score 7.6high
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
This vulnerability involves improper certificate validation in Erlang OTP's public_key modules (pubkey_cert and public_key). The validation logic only enforces DNS nameConstraints on subjectAltName DNS entries, ignoring the subject CommonName when no subjectAltName is present, per RFC 5280. Consequently, a subordinate CA constrained to a DNS subtree can issue a leaf certificate without subjectAltName that is accepted for hostnames outside the permitted DNS subtree due to fallback to the CommonName in hostname verification. This bypass affects OTP versions from 19.3 up to but not including 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1, corresponding to public_key versions before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1. The vulnerability is reachable using stock ssl:connect with verify_peer, trusted CA, SNI, and strict https hostname matcher.
Potential Impact
An attacker controlling a subordinate CA with DNS nameConstraints can issue a leaf certificate without subjectAltName that is accepted by Erlang OTP TLS clients for hostnames outside the permitted DNS subtree. This undermines TLS hostname verification, potentially allowing man-in-the-middle attacks or impersonation of unauthorized hostnames. The vulnerability affects TLS clients using vulnerable OTP versions and can lead to trust violations in secure communications.
Mitigation Recommendations
A patch is available for this vulnerability. The vendor manages remediation for this cloud-hosted service, so users of Erlang OTP cloud services should verify that their provider has applied the fix. For self-managed deployments, upgrade to OTP versions 26.2.5.21, 27.3.4.12, 28.5.0.1, 29.0.1 or later, or corresponding public_key module versions 1.15.1.7, 1.17.1.3, 1.20.3.1, 1.21.1 or later. Check the vendor advisory for the latest remediation guidance.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- EEF
- Date Reserved
- 2026-04-29T18:06:33.251Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
- Is Cloud Service
- true
Threat ID: 6a171ce4e29bf47b50d1de32
Added to database: 5/27/2026, 4:33:40 PM
Last enriched: 5/27/2026, 4:48:54 PM
Last updated: 5/29/2026, 6:04:44 PM
Views: 11
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.