Answer in brief
CVE-2026-42790 records a High severity (CVSS 7.6) vulnerability in nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification. The current sources do not mark it as known exploited. The current feed maps Red Hat/erlang (generic), Red Hat/erlang27 (generic), Erlang/erlang/otp (generic), Erlang/OTP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.6. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Red Hat/erlang (generic), Red Hat/erlang27 (generic), Erlang/erlang/otp (generic), Erlang/OTP (generic) and additional mapped packages. Check affected ranges and fixed versions before updating.
| Product | Affected versions | Fixed versions |
|---|---|---|
| cpe:2.3:a:erlang:erlang\/otp:*:*:*:*:*:*:*:* | Not reported | Not reported |
| Package | Affected range | Fixed version |
|---|---|---|
| Red Hat/erlanggeneric | * | Not reported |
| Red Hat/erlang27generic | * | Not reported |
| Erlang/erlang/otpgeneric | >=19.3 <* || >=b0c245e8132bb13171e277b1af59c0cec00c9459 <* | * |
| Erlang/OTPgeneric | >=19.3 <* || >=b0c245e8132bb13171e277b1af59c0cec00c9459 <* | * |
| Erlang/OTPgeneric | >=1.4 <* | * |
Published upstream
May 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 26, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jul 15, 2026
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.
Quoted source text, attributed separately from HOL analysis.