PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-42790 Erlang CVE debrief

A DNS nameConstraints bypass vulnerability in Erlang/OTP's public_key library allows a subordinate Certificate Authority (CA) with restricted DNS nameConstraints to issue leaf certificates that OTP TLS clients incorrectly accept for out-of-scope hostnames. The vulnerability stems from two interacting flaws in certificate validation and hostname verification. First, the nameConstraints validation logic only checks Subject Alternative Name (SAN) DNS entries against permitted DNS subtrees; certificates lacking a SAN trivially satisfy any DNS nameConstraint regardless of their subject Common Name (CN). Second, hostname verification falls back to the subject CN when no SAN is present, matching it against the reference hostname. A malicious subordinate CA with a permitted DNS constraint (e.g., permitted;DNS:allowed.example.com) can issue a CN-only leaf certificate for victim.example.com; path validation accepts it because no SAN means no nameConstraint trigger, and hostname verification then accepts it via CN fallback. This bypass is reachable using standard ssl:connect with verify_peer, a trusted CA, SNI, and the strict HTTPS hostname matcher. The vulnerability affects OTP versions from 19.3 through fixed releases in the 26.x, 27.x, 28.x, and 29.x branches, corresponding to public_key library versions 1.4 through the respective patched versions.

Vendor
Erlang
Product
OTP
CVSS
HIGH 7.6
CISA KEV
Not listed in stored evidence
Original CVE published
2026-05-27
Original CVE updated
2026-05-27
Advisory published
2026-05-27
Advisory updated
2026-05-27

Who should care

Organizations operating Erlang/OTP-based TLS clients with certificate verification enabled, including telecommunications infrastructure, messaging systems, and distributed applications using ssl:connect with verify_peer. Certificate Authority operators utilizing DNS nameConstraints for subordinate CA restriction should verify their relying parties have patched. Security teams assessing supply chain risk in Erlang-based software distributions.

Technical summary

The vulnerability exists in two components of the Erlang/OTP public_key library. In lib/public_key/src/pubkey_cert.erl, the validate_names/6 function implements RFC 5280 nameConstraints checking but only evaluates DNS-typed entries in the Subject Alternative Name extension. Per RFC 5280 Section 4.2.1.10, a permitted DNS subtree restricts certificates that contain a DNS name; absence of such names means the constraint is not triggered. In lib/public_key/src/public_key.erl, the pkix_verify_hostname/3 function performs hostname verification and falls back to the subject Common Name when no SAN is present, extracting id-at-commonName attributes as presented identifiers. The strict pkix_verify_hostname_match_fun(https) matcher does not suppress this fallback. The combination allows a constrained subordinate CA to issue a leaf certificate with subject CN=victim.example.com and no SAN; path validation accepts it because no DNS SAN exists to trigger the nameConstraint, and hostname verification accepts it because the CN fallback matches the target hostname. The attack requires a trusted CA chain including a DNS-constrained intermediate, network position to present the malicious certificate, and a victim client using standard OTP TLS verification.

Defensive priority

HIGH

Recommended defensive actions

  • Upgrade Erlang/OTP to patched versions: 26.2.5.21 or later, 27.3.4.12 or later, 28.5.0.1 or later, or 29.0.1 or later
  • Upgrade public_key library to patched versions: 1.15.1.7 or later (OTP 26), 1.17.1.3 or later (OTP 27), 1.20.3.1 or later (OTP 28), or 1.21.1 or later (OTP 29)
  • Audit TLS client configurations using ssl:connect with verify_peer to confirm patched library versions are loaded
  • Review certificate validation implementations that rely on public_key:pkix_verify_hostname/3 for custom hostname verification logic
  • Monitor for leaf certificates issued by constrained subordinate CAs that lack Subject Alternative Name extensions
  • Consider implementing additional hostname validation checks independent of the public_key library fallback behavior

Evidence notes

CVE description confirms the vulnerability mechanism involving pubkey_cert:validate_names/6 and public_key:pkix_verify_hostname/3. GitHub commits 0769050c69d73762672b0db1347b6993a5b31759, 21abed64eb2026b5f82f432709e4e932f9be389a, and fb67c6d1836f51105a96d8b769e71e4215a79457 provide fix implementations. GitHub Security Advisory GHSA-22cw-4ph4-6447 documents the coordinated disclosure. CWE-295 (Improper Certificate Validation) and CWE-297 (Improper Validation of Certificate with Host Mismatch) are identified as applicable weakness enumerations.

Official resources

2026-05-27