CVE-2026-42790 Overview
CVE-2026-42790 is an Improper Certificate Validation vulnerability [CWE-295] in the Erlang/OTP public_key application, specifically the pubkey_cert and public_key modules. The flaw allows a DNS nameConstraints bypass during TLS hostname verification by combining two defects: SAN-only nameConstraints checking and a Common Name (CN) fallback in hostname matching. A subordinate Certificate Authority restricted to a DNS subtree can issue a CN-only leaf certificate that Erlang/OTP TLS clients accept for arbitrary out-of-scope hostnames. The issue affects OTP from 19.3 before OTP 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1.
Critical Impact
Attackers controlling a constrained intermediate CA can impersonate any TLS server to Erlang/OTP clients using stock ssl:connect with verify_peer, enabling man-in-the-middle interception of confidential traffic.
Affected Products
- Erlang/OTP 19.3 through 26.2.5.20 (public_key 1.4 through 1.15.1.6)
- Erlang/OTP 27.x before 27.3.4.12 (public_key before 1.17.1.3)
- Erlang/OTP 28.x before 28.5.0.1 (public_key before 1.20.3.1) and 29.0 (public_key before 1.21.1)
Discovery Timeline
- 2026-05-27 - CVE-2026-42790 published to NVD
- 2026-05-27 - Last updated in NVD database
Technical Details for CVE-2026-42790
Vulnerability Analysis
The vulnerability arises from the interaction of two independent weaknesses in Erlang/OTP certificate path validation and hostname verification. Together, they break the trust assumptions an operator relies on when delegating to a name-constrained subordinate CA. An attacker who controls a CA constrained to permitted;DNS:allowed.example.com can issue a leaf valid for victim.example.com and present it to any OTP TLS client.
First, pubkey_cert:validate_names/6 in lib/public_key/src/pubkey_cert.erl checks only Subject Alternative Name (SAN) DNS entries against nameConstraints. Per RFC 5280, a permitted DNS subtree restricts only certificates that contain a DNS-typed name. A leaf without any subjectAltName therefore satisfies the constraint trivially, regardless of its subject Common Name.
Second, public_key:pkix_verify_hostname/3 in lib/public_key/src/public_key.erl falls back to extracting the subject id-at-commonName attributes when no SAN is present and matches them against the reference hostname. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this CN fallback.
Root Cause
The root cause is non-compliance with RFC 9525, which deprecates the use of CN for server identity in TLS. Path validation and hostname verification disagree on what identifies a certificate: nameConstraints inspects SAN, while hostname matching falls back to CN. A CN-only leaf slips through both checks.
Attack Vector
The attack requires a subordinate CA trusted by the OTP client, with DNS nameConstraints restricting the permitted subtree. The attacker issues a leaf certificate omitting subjectAltName and placing the target hostname in the subject CN. When the OTP client connects with ssl:connect, verify_peer, SNI, and the strict https matcher, path validation passes (no SAN, no constraint triggered) and hostname verification accepts the CN. The attacker can then intercept TLS traffic for any victim hostname.
%% PresentedIDs example: [{dNSName,"ewstest.ericsson.com"}, {dNSName,"www.ericsson.com"}]}
case PresentedIDs of
[] ->
- %% Fallback to CN-ids [rfc6125, ch6]
- case TbsCert#'OTPTBSCertificate'.subject of
- {rdnSequence,RDNseq} ->
- PresentedCNs =
- [{cn, to_string(V)}
- || ATVs <- RDNseq,
- #'AttributeTypeAndValue'{type = ?'id-at-commonName',
- value = {_T,V}} <- ATVs
- ],
- verify_hostname_match_loop(verify_hostname_fqnds(ReferenceIDs, FqdnFun),
- PresentedCNs,
- MatchFun, FailCB, Cert);
- _ ->
- false
- end;
- _ ->
+ false;
+ _ ->
%% match ReferenceIDs to PresentedIDs
case verify_hostname_match_loop(ReferenceIDs, PresentedIDs,
MatchFun, FailCB, Cert) of
Source: GitHub Commit 0769050. The patch removes the CN-ID fallback in pkix_verify_hostname to align with RFC 9525, causing verification to fail when no SAN is present.
Detection Methods for CVE-2026-42790
Indicators of Compromise
- Server certificates presented to Erlang/OTP TLS clients that contain a subject Common Name matching a service hostname but no subjectAltName extension.
- Leaf certificates issued by an intermediate CA bearing nameConstraints extensions where the leaf omits SAN entries.
- Unexpected TLS handshakes from Erlang/OTP applications to hostnames outside the documented intermediate CA scope.
Detection Strategies
- Inventory all Erlang/OTP deployments and identify versions of the public_key application; flag any below the fixed releases.
- Scan certificate stores and PKI inventories for CA certificates with nameConstraints and audit their issued leaves for missing SAN extensions.
- Capture TLS traffic from Erlang/OTP services and verify presented certificates include SAN DNS entries matching the connected hostname.
Monitoring Recommendations
- Log certificate chain details from OTP clients using ssl:connection_information/2 and alert on chains lacking SAN on the leaf.
- Monitor outbound TLS connections from Erlang services for unexpected destinations or certificate issuers.
- Track the CT (Certificate Transparency) logs of any internal CA infrastructure for unusual issuance patterns under name-constrained intermediates.
How to Mitigate CVE-2026-42790
Immediate Actions Required
- Upgrade Erlang/OTP to 26.2.5.21, 27.3.4.12, 28.5.0.1, 29.0.1, or later, which correspond to public_key 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.
- Audit trusted CA stores used by Erlang/OTP applications and remove any name-constrained intermediates that are not strictly required.
- Reject server certificates lacking a subjectAltName extension at the application layer until the patch is applied.
Patch Information
The Erlang Ecosystem Foundation released fixes across maintained OTP branches. See the GitHub Security Advisory GHSA-22cw-4ph4-6447 and the CNA advisory for CVE-2026-42790. The fix commits are commit 0769050, commit 21abed6, and commit fb67c6d, which align pkix_verify_hostname with RFC 9525 by removing the CN fallback.
Workarounds
- Supply a custom verify_fun to ssl:connect/3 that rejects any peer certificate missing a subjectAltName extension.
- Replace the default hostname matcher with a strict matcher that ignores subject Common Name attributes entirely.
- Restrict trust anchors to publicly trusted CAs that enforce SAN requirements (CA/Browser Forum Baseline Requirements).
# Verify installed Erlang/OTP and public_key versions
erl -eval 'io:format("OTP: ~s~npublic_key: ~s~n", [erlang:system_info(otp_release), element(2, application:get_key(public_key, vsn))]), halt().' -noshell
# Example application-layer guard: reject certificates without SAN
# (apply inside a custom verify_fun passed to ssl:connect/3)
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
