CVE-2026-32144: Erlang OTP Auth Bypass Vulnerability

CVE-2026-32144 Overview

CVE-2026-32144 is an Improper Certificate Validation vulnerability (CWE-295) in Erlang OTP's public_key module, specifically within the pubkey_ocsp module responsible for Online Certificate Status Protocol (OCSP) response validation. The vulnerability allows attackers to bypass OCSP designated-responder authorization by exploiting missing signature verification in the public_key:pkix_ocsp_validate/5 function.

The OCSP response validation mechanism fails to cryptographically verify that a CA-designated responder certificate was actually signed by the issuing Certificate Authority. Instead, it only performs superficial checks—matching the responder certificate's issuer name against the CA's subject name and verifying the presence of the OCSPSigning extended key usage (EKU). This insufficient validation enables attackers with network interception capabilities to forge OCSP responses using self-signed certificates, causing revoked certificates to be accepted as valid.

Critical Impact

SSL/TLS clients using OCSP stapling may accept connections to servers presenting revoked certificates, potentially transmitting sensitive data to compromised endpoints. Applications directly using the public_key:pkix_ocsp_validate/5 API are also vulnerable.

Affected Products

• Erlang OTP versions 27.0 through 28.4.2 (fixed in 28.4.2 and 27.3.4.10)
• public_key library versions 1.16 through 1.20.3 (fixed in 1.20.3 and 1.17.1.2)
• ssl library versions 11.2 through 11.5.4 (fixed in 11.5.4 and 11.2.12.7)

Discovery Timeline

• 2026-04-07 - CVE-2026-32144 published to NVD
• 2026-04-07 - Last updated in NVD database

Technical Details for CVE-2026-32144

Vulnerability Analysis

The vulnerability resides in the pubkey_ocsp:is_authorized_responder/3 routine within lib/public_key/src/pubkey_ocsp.erl. RFC 6960 specifies three methods for authorizing OCSP responders, with the second method (designated responder) requiring that the responder certificate be cryptographically signed by the CA that issued the certificate being checked.

The flawed implementation only verifies two conditions: that the responder certificate's issuer Distinguished Name (DN) matches the CA's subject DN, and that the certificate contains the id-kp-OCSPSigning extended key usage. This allows an attacker to create a self-signed certificate with an arbitrary issuer name that matches the target CA's subject name, include the OCSPSigning EKU, and use this certificate to sign forged OCSP responses.

The attack is particularly dangerous in SSL/TLS contexts using OCSP stapling, where servers provide OCSP responses during the TLS handshake. A compromised or malicious server could present a revoked certificate along with a forged OCSP response claiming the certificate is valid, completely bypassing certificate revocation checking.

Root Cause

The root cause is the missing cryptographic signature verification step in the designated responder authorization check. The is_authorized_responder/3 function verifies administrative properties (issuer name match, EKU presence) but omits the critical call to public_key:pkix_verify/2 that would confirm the CA actually issued the responder certificate. This violates RFC 6960 Section 4.2.2.2, which mandates that designated responders must hold certificates "issued directly by the CA that issued the certificate in question."

Attack Vector

An attacker positioned to intercept or control OCSP responses (via man-in-the-middle attack, DNS hijacking, or control of a malicious server) can exploit this vulnerability through the following mechanism:

1. Generate a self-signed certificate with the issuer DN set to match the target CA's subject DN
2. Include the id-kp-OCSPSigning (1.3.6.1.5.5.7.3.9) extended key usage in the certificate
3. Use this certificate to sign OCSP responses indicating that revoked certificates have a "good" status
4. Present these forged responses to clients using OCSP stapling or direct OCSP queries

The security patch adds the missing signature verification check:

         %%      issue OCSP responses for that CA (id-kp-OCSPSigning)
         fun() ->
                 public_key:pkix_is_issuer(ResponderCert, IssuerCert) andalso
-                                 designated_for_ocsp_signing(ResponderCert)
+                    designated_for_ocsp_signing(ResponderCert) andalso
+                    public_key:pkix_verify(CombinedResponderCert#cert.der,
+                                           get_public_key_rec(IssuerCert))
         end,
     Case3 =
         %% a Trusted Responder whose public key is trusted by the requestor

Source: GitHub OTP Commit 49033a6

Detection Methods for CVE-2026-32144

Indicators of Compromise

• OCSP responses signed by certificates not issued by the expected CA certificate chain
• TLS connections established with servers presenting certificates that should be revoked
• OCSP responder certificates with mismatched cryptographic chain validation
• Unexpected self-signed certificates with OCSPSigning EKU in network traffic

Detection Strategies

• Audit applications using Erlang OTP versions 27.0 through 28.4.1 for direct usage of public_key:pkix_ocsp_validate/5 API
• Review TLS configurations for OCSP stapling enablement across affected Erlang-based services
• Implement network-level monitoring for OCSP response anomalies, particularly responses signed by unexpected certificates
• Scan for Erlang OTP installations using package management inventory or file system searches for pubkey_ocsp.beam

Monitoring Recommendations

• Enable verbose logging for SSL/TLS certificate validation in Erlang applications
• Monitor certificate transparency logs for unexpected certificates issued to your domains
• Implement alerting for certificate revocation status mismatches between OCSP and CRL sources
• Deploy network detection for OCSP responses with responder certificates not in expected CA chains

How to Mitigate CVE-2026-32144

Immediate Actions Required

• Upgrade Erlang OTP to version 28.4.2 or 27.3.4.10 immediately
• For public_key library users, update to version 1.20.3 or 1.17.1.2
• For ssl library users, update to version 11.5.4 or 11.2.12.7
• Audit all Erlang-based applications for OCSP stapling configuration and direct OCSP API usage

Patch Information

Official security patches are available through the Erlang OTP repository. The vulnerability is addressed in commits 49033a6 and ac7ff52. Users should upgrade to the fixed versions:

• OTP 28.4.2 or later (for OTP 28.x branch)
• OTP 27.3.4.10 or later (for OTP 27.x branch)

Additional details are available in the GitHub Security Advisory GHSA-gxrm-pf64-99xm and the CNA CVE Details.

Workarounds

• Disable OCSP stapling in SSL/TLS configurations until patches can be applied
• Use Certificate Revocation Lists (CRLs) as an alternative revocation checking mechanism
• Implement additional certificate chain validation at the application layer
• Consider network-level controls to restrict OCSP traffic to known, trusted responders

# Example: Disable OCSP stapling in Erlang SSL options
# When configuring ssl:listen/2 or ssl:connect/3, ensure ocsp_stapling is disabled
# until patched versions are deployed

# Erlang shell example for checking current OTP version
erl -eval 'io:format("~s~n", [erlang:system_info(otp_release)]), halt().'

# Verify installed public_key version
erl -eval 'application:load(public_key), {ok, V} = application:get_key(public_key, vsn), io:format("~s~n", [V]), halt().'