Erlang/OTP EUVD-2026-32558

Exploitation requires that the victim run an affected OTP version's TLS client via ssl:connect with verify_peer and a trust anchor chain that includes a subordinate CA carrying DNS nameConstraints (a permitted;DNS:... subtree), and that the attacker be able to make that constrained CA issue a leaf certificate that has NO subjectAltName extension and a subject CommonName equal to the targeted out-of-scope hostname. The client must use SNI and the canonical strict https hostname matcher (pkix_verify_hostname_match_fun(https)) - the default secure configuration, which is precisely what makes the bypass notable. Limiting factors per the CVSS vector: the connection must be initiated by the victim (UI:P, passive interaction), the attacker needs network position to present the forged certificate, and the high complexity (AC:H/AT:P) reflects the hard prerequisite of controlling a trusted, name-constrained intermediate CA - without such a CA in the victim's trust path the bypass is not reachable. It does NOT require credentials on the target (PR:N). Certificates that include a SAN, or clients using a custom match_fun that ignores CN, are not affected.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N) is internally consistent with the description and tells the real story: network reachable and unauthenticated (PR:N) with high confidentiality and integrity impact (a successful identity bypass enables full MITM), but gated by high attack complexity (AC:H), present attack requirements (AT:P), and passive user interaction (UI:P). Those gates matter - the attacker must already control a subordinate CA that the victim's trust store accepts AND that carries DNS nameConstraints, which is an uncommon precondition (typical of constrained enterprise/partner PKI or a mis-scoped delegated CA), and the victim must initiate the TLS connection. No EPSS score was provided in the intelligence, so exploitation probability cannot be quantified here; there is no CISA KEV listing and no POC referenced, so this is not evidence of active or widespread exploitation. Net: a genuine, high-impact certificate-validation flaw worth prioritized patching for anyone running TLS clients on affected OTP versions, but real-world exploitation is constrained to environments where an adversary can obtain a trusted, name-constrained intermediate rather than being mass-exploitable. The Authentication Bypass tag reflects the impact class; treat the 7.6 as 'fix promptly' rather than 'emergency in-the-wild' absent EPSS/KEV signals.

An attacker who controls or compromises a subordinate CA that the target's OTP TLS client trusts - but whose certificate carries DNS nameConstraints limiting it to permitted;DNS:allowed.example.com - issues a leaf certificate with no subjectAltName and CN=victim.example.com. Because the SAN-less leaf never triggers the DNS nameConstraints check, path validation succeeds, and the client's strict https hostname matcher then accepts the certificate via its CommonName fallback. The attacker, positioned on the network path, presents this certificate when the victim client connects to victim.example.com and transparently intercepts or alters the TLS session; no public exploit code has been identified at time of analysis.