Improper certificate validation in Erlang OTP public_key modules permits a DNS nameConstraints bypass by using a certificate that contains only a CommonName and no subjectAltName. The combination of two flaws—pubkey_cert:validate_names only checking SAN entries against nameConstraints, and public_key:pkix_verify_hostname falling back to the CommonName when SAN is absent—allows a subordinate CA with DNS nameConstraints (e.g., permitted;DNS:allowed.example.com) to issue a leaf certificate that an OTP TLS client will accept as a valid identity for an out‑of‑scope hostname such as victim.example.com. Consequently, an attacker could impersonate a target domain using a stock ssl:connect with verify_peer, a trusted CA, SNI, and the standard https hostname matcher. This flaw is exploited by path validation accepting the CN-only leaf under a DNS‑constrained intermediate, and hostname verification subsequently accepting it via the CN fallback.

The vulnerable products are Erlang OTP releases 19.3 through 29.0.1, including the intermediate releases 26.2.5.21, 27.3.4.12, and 28.5.0.1, as well as the corresponding public_key modules 1.4, 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.

With a CVSS score of 7.6 the vulnerability is moderate to high in severity, while the EPSS score of < 1% indicates a very low probability of exploitation. It is not listed in the CISA KEV catalog. Exploitation requires an attacker to control a server that presents a TLS chain in which a subordinate CA whose nameConstraints restrict DNS names issues a leaf certificate that contains only a CommonName. An OTP client using the default ssl:connect with verify_peer, a trusted CA, SNI, and the standard https hostname matcher will accept that chain, allowing the attacker to impersonate the target domain. Because the flaw is limited to hostname verification, it does not provide remote code execution or other high‑impact access beyond identity spoofing.