CVE-2026-32144: 
Erlang OTP vulnerability analysis and mitigation

CVE-2026-32144 is an Improper Certificate Validation vulnerability in Erlang OTP's public_key library (pubkey_ocsp module) that allows an OCSP designated-responder authorization bypass via missing cryptographic signature verification. Disclosed on April 7, 2026, it affects Erlang/OTP versions 27.0 through 27.3.4.10 and 28.0 through 28.4.2, corresponding to public_key 1.16–1.20.3/1.17.1.2 and ssl 11.2–11.5.4/11.2.12.7. The vulnerability was discovered by Igor Morgenstern at Aisle Research and responsibly disclosed to the Erlang/OTP project. It carries a CVSS v3.1 base score of 7.4 (High) and a CVSS v4.0 base score of 7.6 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-295 (Improper Certificate Validation) and CWE-347 (Improper Verification of Cryptographic Signature). The vulnerable function pubkey_ocsp:is_authorized_responder/3 in lib/public_key/src/pubkey_ocsp.erl implements Case 2 of RFC 6960 §4.2.2.2 (designated OCSP responder) but only checks that the responder certificate's issuer Distinguished Name (DN) matches the CA's subject DN and that the certificate carries the id-kp-OCSPSigning Extended Key Usage — it does not call public_key:pkix_verify/2 to confirm the CA cryptographically signed the responder certificate. An attacker who can intercept or control OCSP responses (e.g., via a man-in-the-middle position or by operating a rogue OCSP responder) can craft a self-signed certificate with the CA's subject DN and the OCSPSigning EKU, then use it to sign forged OCSP responses. The fix, applied in commits ac7ff52 and 49033a6, adds a public_key:pkix_verify/2 call to enforce cryptographic signature verification of the designated responder certificate (GitHub Commit, GitHub Advisory).

Successful exploitation allows an attacker to forge OCSP responses that mark revoked certificates as valid, causing SSL/TLS clients using OCSP stapling to accept connections to servers presenting revoked certificates. This can result in sensitive data being transmitted to compromised or attacker-controlled servers, impacting both confidentiality and integrity. Applications using the public_key:pkix_ocsp_validate/5 API directly are also affected; in server-side client certificate validation scenarios, this could lead to authentication bypass. Availability is not directly impacted (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). Exploitation requires the attacker to be in a position to intercept or control OCSP responses (e.g., network MITM or rogue OCSP infrastructure), which raises the practical bar. The EPSS score is approximately 0.035% (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Prerequisite — Attain MITM or OCSP control: Position yourself to intercept OCSP traffic between the target TLS client and the legitimate OCSP responder, or operate a rogue OCSP responder reachable by the target (e.g., via DNS spoofing, BGP hijacking, or ARP poisoning on the local network).
2. Identify target CA: Determine the issuing CA's subject Distinguished Name (DN) for the certificate whose revocation status you wish to forge. This is publicly available from the certificate chain presented during TLS handshake.
3. Forge a designated responder certificate: Generate a new key pair and create a self-signed X.509 certificate with the issuer and subject DN set to the target CA's subject DN, and include the id-kp-OCSPSigning Extended Key Usage extension. Sign this certificate with your own private key (not the CA's).
4. Craft a forged OCSP response: Construct a BasicOCSPResponse that reports the target revoked certificate as good (valid). Sign the OCSP response data using the private key corresponding to the forged responder certificate.
5. Deliver the forged response: Intercept the OCSP stapling request from the vulnerable TLS client and return the forged OCSP response along with the forged responder certificate.
6. Bypass revocation check: The vulnerable pubkey_ocsp:is_authorized_responder/3 function accepts the forged certificate (DN matches, OCSPSigning EKU present) without verifying the CA's cryptographic signature, causing the client to treat the revoked certificate as valid and complete the TLS handshake with the attacker-controlled server (GitHub Advisory, GitHub Commit).

• Network: Unexpected OCSP responses originating from IP addresses not associated with the legitimate CA's OCSP infrastructure; OCSP responses containing responder certificates that are self-signed (issuer DN equals subject DN) rather than CA-signed.
• Network: TLS connections established to servers whose certificates are known to be revoked, particularly when OCSP stapling is enabled on the client.
• Logs: TLS/SSL library logs showing OCSP validation succeeding for certificates that should be revoked; absence of expected OCSP responder hostnames in connection logs.
• File System / Configuration: Unexpected changes to OCSP responder URL configurations or SSL options in Erlang application configuration files.
• Process Behavior: Erlang SSL processes (ssl_manager, ssl_connection) completing handshakes with servers presenting certificates that fail CRL-based revocation checks when cross-validated.

Upgrade Erlang/OTP to patched versions: OTP 27.3.4.10 or OTP 28.4.2 (corresponding to public_key 1.17.1.2 or 1.20.3, and ssl 11.2.12.7 or 11.5.4). For TLS/SSL users unable to patch immediately, disable OCSP stapling (the current default {stapling, no_staple} is already safe) or switch to CRL-based revocation checking using the {crl_check, true} SSL option. For applications calling public_key:pkix_ocsp_validate/5 directly, pass the {is_trusted_responder_fun, Fun} option with a function that independently validates trusted responder certificates, or restrict OCSP responder access to trusted endpoints via network controls (GitHub Advisory, Red Hat Bugzilla).

The Erlang/OTP project published a GitHub Security Advisory (GHSA-gxrm-pf64-99xm) crediting Igor Morgenstern at Aisle Research for responsible disclosure. Patch announcements were posted to the Erlang Forums for both OTP 28.4.2 and OTP 27.3.4.10, and the Elixir community forum also noted the release. OpenSUSE issued a security announcement for updated Erlang packages, and Tenable published Nessus detection plugins (IDs 305609 and 310082) for the vulnerability (GitHub Advisory, Erlang Forums OTP 28.4.2, Erlang Forums OTP 27.3.4.10).