CVE-2026-42790: Erlang OTP Auth Bypass Vulnerability

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)