Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeyocsp module) allows OCSP designated-responder authorization bypass via missing signature verification.
The OCSP response validation in publickey:pkixocspvalidate/5 does not verify that a CA-designated responder certificate was cryptographically signed by the issuing CA. Instead, it only checks that the responder certificate's issuer name matches the CA's subject name and that the certificate has the OCSPSigning extended key usage. An attacker who can intercept or control OCSP responses can create a self-signed certificate with a matching issuer name and the OCSPSigning EKU, and use it to forge OCSP responses that mark revoked certificates as valid.
This affects SSL/TLS clients using OCSP stapling, which may accept connections to servers with revoked certificates, potentially transmitting sensitive data to compromised servers. Applications using the publickey:pkixocspvalidate/5 API directly are also affected, with impact depending on usage context.
This vulnerability is associated with program files lib/publickey/src/pubkeyocsp.erl and program routines pubkeyocsp:isauthorizedresponder/3.
This issue affects OTP from OTP 27.0 before OTP 28.4.2 and OTP 27.3.4.10, corresponding to publickey from 1.16 before 1.20.3 and 1.17.1.2, and ssl from 11.2 before 11.5.4 and 11.2.12.7.
Improper Certificate Validation vulnerability in Erlang OTP publickey (pubkeycert and publickey 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, pubkeycert:validatenames/6 in lib/publickey/src/pubkeycert.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, publickey:pkixverifyhostname/3 in lib/publickey/src/publickey.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 pkixverifyhostnamematchfun(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 verifypeer, 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 publickey from 1.4 before 1.15.1.7, 1.17.1.3, 1.20.3.1, and 1.21.1.