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 CVE-2026-42790 in Erlang OTP's public_key module involves improper certificate validation that enables a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Specifically, the function pubkey_cert:validate_names/6 only checks DNS entries in the subjectAltName extension against nameConstraints, ignoring the subject CommonName when no subjectAltName is present. According to RFC 5280, a permitted DNS subtree restriction applies only to DNS-typed names in subjectAltName, so a leaf certificate without subjectAltName trivially satisfies any permitted DNS nameConstraints regardless of its CommonName. Additionally, the hostname verification function public_key:pkix_verify_hostname/3 falls back to matching the CommonName if no subjectAltName exists, allowing acceptance of out-of-scope hostnames. This combination allows a subordinate CA restricted by DNS nameConstraints to issue a leaf certificate accepted for hostnames outside the permitted DNS subtree. The vulnerability affects Erlang OTP versions from OTP 19.3 up to but not including OTP 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12, and OTP 26.2.5.21, corresponding to public_key versions from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3, and 1.15.1.7. The issue is exploitable via the standard ssl:connect function with verify_peer enabled, a trusted CA, SNI, and the strict https hostname matcher. Red Hat has released security updates addressing this issue in their Erlang packages for OpenStack Services on OpenShift 18.0.
Potential Impact
This vulnerability allows an attacker controlling a subordinate CA with DNS nameConstraints restrictions to issue a leaf certificate without subjectAltName that is accepted by Erlang OTP TLS clients for hostnames outside the permitted DNS subtree. This leads to hostname spoofing during TLS connections, potentially enabling man-in-the-middle attacks or impersonation of services. The vulnerability affects TLS hostname verification in Erlang OTP, impacting applications relying on Erlang's ssl module for secure communications. The CVSS 4.0 base score is 7.6 (high severity), reflecting network attack vector, high impact on confidentiality and integrity, and partial attack complexity and user interaction requirements.
Mitigation Recommendations
A patch is available and should be applied to affected Erlang OTP versions. Red Hat has released updated Erlang packages for OpenStack Services on OpenShift 18.0 that address this vulnerability. For cloud services using Erlang OTP, the vendor manages remediation server-side. Users should consult the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-42790 and apply the recommended updates promptly. No additional mitigation steps are indicated beyond applying the official fixes.
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
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 CVE-2026-42790 in Erlang OTP's public_key module involves improper certificate validation that enables a DNS nameConstraints bypass via subject CommonName fallback in TLS hostname verification. Specifically, the function pubkey_cert:validate_names/6 only checks DNS entries in the subjectAltName extension against nameConstraints, ignoring the subject CommonName when no subjectAltName is present. According to RFC 5280, a permitted DNS subtree restriction applies only to DNS-typed names in subjectAltName, so a leaf certificate without subjectAltName trivially satisfies any permitted DNS nameConstraints regardless of its CommonName. Additionally, the hostname verification function public_key:pkix_verify_hostname/3 falls back to matching the CommonName if no subjectAltName exists, allowing acceptance of out-of-scope hostnames. This combination allows a subordinate CA restricted by DNS nameConstraints to issue a leaf certificate accepted for hostnames outside the permitted DNS subtree. The vulnerability affects Erlang OTP versions from OTP 19.3 up to but not including OTP 29.0.1, OTP 28.5.0.1, OTP 27.3.4.12, and OTP 26.2.5.21, corresponding to public_key versions from 1.4 before 1.21.1, 1.20.3.1, 1.17.1.3, and 1.15.1.7. The issue is exploitable via the standard ssl:connect function with verify_peer enabled, a trusted CA, SNI, and the strict https hostname matcher. Red Hat has released security updates addressing this issue in their Erlang packages for OpenStack Services on OpenShift 18.0.
Potential Impact
This vulnerability allows an attacker controlling a subordinate CA with DNS nameConstraints restrictions to issue a leaf certificate without subjectAltName that is accepted by Erlang OTP TLS clients for hostnames outside the permitted DNS subtree. This leads to hostname spoofing during TLS connections, potentially enabling man-in-the-middle attacks or impersonation of services. The vulnerability affects TLS hostname verification in Erlang OTP, impacting applications relying on Erlang's ssl module for secure communications. The CVSS 4.0 base score is 7.6 (high severity), reflecting network attack vector, high impact on confidentiality and integrity, and partial attack complexity and user interaction requirements.
Mitigation Recommendations
A patch is available and should be applied to affected Erlang OTP versions. Red Hat has released updated Erlang packages for OpenStack Services on OpenShift 18.0 that address this vulnerability. For cloud services using Erlang OTP, the vendor manages remediation server-side. Users should consult the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-42790 and apply the recommended updates promptly. No additional mitigation steps are indicated beyond applying the official fixes.
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
- 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: 07/30/2026, 03:33:06 UTC
Last updated: 07/31/2026, 19:22:58 UTC
Views: 53
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.