Erlang OTP prior 29.0.1 pubkey_cert.erl pubkey_cert certificate validation

Summaryinfo

A vulnerability, which was classified as problematic, has been found in Erlang OTP. The impacted element is the function pubkey_cert in the library lib/public_key/src/pubkey_cert.erl. The manipulation leads to certificate validation. This vulnerability is referenced as CVE-2026-42790. Remote exploitation of the attack is possible. No exploit is available. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability was found in Erlang OTP and classified as problematic. This issue affects the function pubkey_cert in the library lib/public_key/src/pubkey_cert.erl. The manipulation with an unknown input leads to a certificate validation vulnerability. Using CWE to declare the problem leads to CWE-295. The product does not validate, or incorrectly validates, a certificate. Impacted is integrity. The summary by CVE is:

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 26.2.5.21, 27.3.4.12, 28.5.0.1, and 29.0.1 corresponding to public_key from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

The weakness was published by John Downey. It is possible to read the advisory at github.com. The identification of this vulnerability is CVE-2026-42790 since 04/29/2026. The exploitation is known to be difficult. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1587.003 according to MITRE ATT&CK.

Upgrading to version 1.4, 1.15.1.7, 1.17.1.3, 1.20.3.1, 1.21.1, 19.3, 26.2.5.21, 27.3.4.12, 28.5.0.1 or 29.0.1 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• Erlang

Name

• OTP

Website

• Product: https://github.com/erlang/otp/

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion