Listen to this Post
Intro – How CVE-2026-42790 Works
This vulnerability combines two logical flaws in Erlang/OTP’s certificate validation and hostname verification. The first flaw lies in `pubkey_cert:validate_names/6` (lib/public_key/src/pubkey_cert.erl). When a subordinate CA has a DNS `nameConstraints` extension (e.g., permitted;DNS:allowed.example.com), the function only checks Subject Alternative Name (SAN) DNS entries against those constraints. According to RFC 5280, a `permitted;DNS` subtree restricts only certificates that actually contain a DNS‑typed name. Therefore, a leaf certificate that has no subjectAltName extension trivially satisfies any `permitted;DNS` constraint – the constraint is simply not triggered because there is no SAN field to compare. The second flaw occurs in `public_key:pkix_verify_hostname/3` (lib/public_key/src/public_key.erl). When a certificate lacks a subjectAltName, this function falls back to the subject’s Common Name (CN) attribute. It extracts the `id-at-commonName` value and matches it against the reference hostname provided by the caller. The strict matcher `pkix_verify_hostname_match_fun(https)` does not disable this CN fallback. An attacker who controls a subordinate CA with restrictive DNS nameConstraints (e.g., only allowed to issue for .allowed.example.com) can craft a leaf certificate that omits the SAN extension entirely, instead setting the subject CN to an out‑of‑scope hostname like victim.example.com. The path validation step accepts the leaf because the absence of SAN bypasses the nameConstraints check. Then the TLS hostname verification accepts the leaf via the CN fallback, treating `victim.example.com` as a valid identity. This bypass is reachable from a stock `ssl:connect` call with verify_peer, a trusted CA chain, SNI, and the default strict `https` hostname matcher. The vulnerability affects OTP versions from OTP 19.3 up to (but not including) OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 – corresponding to `public_key` versions prior to 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
DailyCVE Form:
Platform: Erlang/OTP
Version: 19.3 before 29.0.1
Vulnerability: Certificate validation bypass
Severity: Critical
date: 05/27/2026
Prediction: Already patched in 29.0.1
What Undercode Say:
Generate a malicious intermediate CA with nameConstraints
openssl genrsa -out intermediate.key 2048
openssl req -new -key intermediate.key -out intermediate.csr -subj "/CN=Malicious Intermediate CA"
openssl x509 -req -in intermediate.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out intermediate.crt -extfile <(echo "nameConstraints=permitted;DNS:allowed.example.com")
Create a leaf certificate with NO subjectAltName, only CN = victim.example.com
openssl genrsa -out leaf.key 2048
openssl req -new -key leaf.key -out leaf.csr -subj "/CN=victim.example.com"
openssl x509 -req -in leaf.csr -CA intermediate.crt -CAkey intermediate.key -CAcreateserial -out leaf.crt -days 365
Verify the chain – OTP client will accept leaf as valid for victim.example.com
(Erlang snippet)
echo "
ssl:connect(\"victim.example.com\", 443, [{cacertfile, \"rootCA.crt\"}, {verify, verify_peer}, {server_name_indication, \"victim.example.com\"}, {customize_hostname_check, [{match_fun, public_key:pkix_verify_hostname_match_fun(https)}]}]).
" | erl
Exploit:
An attacker who has obtained (or can compromise) a subordinate CA whose `nameConstraints` restrict it to a specific DNS subtree (e.g., allowed.example.com) issues a leaf certificate for a victim hostname outside that subtree (victim.example.com). The leaf certificate omits the `subjectAltName` extension entirely and places the victim hostname inside the subject Common Name. When an Erlang/OTP TLS client (e.g., an SSL‑enabled web client or an HTTPS API caller) connects to the attacker’s server presenting this leaf + intermediate chain, the client’s path validation does not enforce the `nameConstraints` because there is no SAN to check. The hostname verification then falls back to the CN, matches victim.example.com, and the connection succeeds. The attacker can therefore impersonate any hostname not covered by the intermediate CA’s constraints.
Protection:
- Upgrade Erlang/OTP to a fixed version: OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, or 29.0.1 (or any later release).
- If upgrading is not immediately possible, patch `public_key` to the corresponding fixed versions: 1.15.1.7, 1.17.1.3, 1.20.3.1, or 1.21.1.
- As a temporary mitigation, configure hostname verification to reject CN fallback by using a custom match function that requires a SAN DNS entry.
Impact:
Successful exploitation allows a subordinate CA with DNS `nameConstraints` to issue a leaf certificate that is accepted by Erlang/OTP TLS clients for any hostname, completely bypassing the intended restriction. This enables Man‑in‑the‑Middle (MitM) attacks, spoofing of arbitrary domain names, and unauthorized access to services that rely on certificate‑based authentication (e.g., HTTPS, STARTTLS, or custom SSL‑protected Erlang distribution). The attack requires no user interaction and works with the default `verify_peer` settings.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
