CVE-2026-42790
highpriority · track · 32EPSS 0.003 · 28 %ileDEEURUUSEPSS · scored 2026-10-27
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.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · medium–high · 4.9–8.1
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (41)
Products and version ranges known to be affected.
- Red Hat OpenShift OpenStack Servicesall versionscert_bundDEcpe:/a:redhat:openshift:openstack_services
advisories (2)
Vendor and ecosystem advisories describing this.
- WID-SEC-W-2026-1719Erlang/OTP: Mehrere Schwachstellen ermöglichen Umgehen von SicherheitsvorkehrungenDeutsch2026-05-27csaf · cert_bundDE
Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Erlang/OTP ausnutzen, um Sicherheitsvorkehrungen zu umgehen.
- EEF-CVE-2026-42790nameConstraints DNS bypass via subject CommonName fallback in public_key hostname verification2026-05-27vendor · osvUS
## Summary 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. ## Workarounds The verify\_fun option in the ssl application can be used to ensure that TLS connections fail if the end-entity certificate is missing the subjectAltName extension or has no domain name. Do not use a verify\_fun that accepts the name\_not\_permitted error.
also known as (4)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (28)
External citations — patches, advisories, analysis.
- https://access.redhat.com/security/cve/cve-2026-42790cnnvd
- https://cna.erlef.org/cves/CVE-2026-42790.htmlcnnvd
- https://github.com/erlang/otp/commit/0769050c69d73762672b0db1347b6993a5b31759cnnvd
- https://github.com/erlang/otp/commit/21abed64eb2026b5f82f432709e4e932f9be389acnnvd
- https://github.com/erlang/otp/commit/fb67c6d1836f51105a96d8b769e71e4215a79457cnnvd
- https://github.com/erlang/otp/releasesPatchcnnvd
- https://github.com/erlang/otp/security/advisories/GHSA-22cw-4ph4-6447cnnvd
- https://osv.dev/vulnerability/EEF-CVE-2026-42790cnnvd
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan