CVE-2026-42791: Erlang OTP Auth Bypass Vulnerability

CVE-2026-42791 Overview

CVE-2026-42791 is an improper certificate validation flaw [CWE-295] in the Erlang/OTP public_key application, specifically the pubkey_ocsp module. The Online Certificate Status Protocol (OCSP) response verification logic does not check the validity period of the OCSP responder certificate. An attacker holding the private key of an expired CA-designated responder certificate can forge OCSP responses that Erlang/OTP accepts as valid. TLS clients using OCSP stapling through the ssl application, and applications calling public_key:pkix_ocsp_validate/5 directly, treat revoked certificates as valid. The issue affects OTP 27.0 through versions before 27.3.4.12, 28.5.0.1, and 29.0.1.

Critical Impact
A compromised server can present a revoked TLS certificate with a forged OCSP response, and Erlang/OTP clients will accept the revoked certificate as valid. Server-side client certificate validation may allow authentication bypass with revoked client credentials.

Affected Products

Erlang/OTP 27.0 through versions before 27.3.4.12
Erlang/OTP 28.x before 28.5.0.1
Erlang/OTP 29.x before 29.0.1 (public_key 1.16 through versions before 1.17.1.3, 1.20.3.1, and 1.21.1)

Discovery Timeline

2026-05-27 - CVE-2026-42791 published to NVD
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-42791

Vulnerability Analysis

The vulnerability resides in pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3 within lib/public_key/src/pubkey_ocsp.erl. These functions verify the cryptographic signature on an OCSP response and confirm that the signer is a CA-designated responder. They do not validate the notBefore and notAfter fields of the responder certificate. An expired responder certificate is therefore treated as a trust anchor for OCSP response validity. The flaw is classified under [CWE-295: Improper Certificate Validation].

Root Cause

The root cause is a missing temporal check during OCSP responder authorization. RFC 6960 requires that a responder certificate be valid at the time the response is produced. The Erlang implementation enforces signature validity and key-usage extensions but omits validity-period enforcement. Once a CA delegates OCSP signing to a responder, the responder's private key effectively retains revocation-bypass authority beyond its intended lifetime.

Attack Vector

Exploitation requires the attacker to possess the private key of a previously valid, now-expired OCSP responder certificate issued by a CA in the victim's trust path. The attacker also needs control of a TLS endpoint or position to deliver a stapled OCSP response. The attacker forges an OCSP response asserting good status for a revoked certificate, signs it with the expired responder key, and serves it during the TLS handshake. The Erlang/OTP client accepts the revoked certificate. In server-side mTLS use cases that call public_key:pkix_ocsp_validate/5, this enables authentication bypass with a revoked client certificate.

No public proof-of-concept code is available. See the GitHub Security Advisory GHSA-cjxj-wj6x-3fff and the CNA advisory for technical details.

Detection Methods for CVE-2026-42791

Indicators of Compromise

OCSP responses signed by responder certificates whose notAfter date has passed prior to the response producedAt timestamp.
TLS sessions to or from Erlang/OTP services where the peer certificate appears on a CA Certificate Revocation List (CRL) but the session was accepted.
Stapled OCSP responses whose signer certificate chain includes an expired delegated responder.

Detection Strategies

Parse captured OCSP responses (from TLS handshakes or ssl debug logs) and compare the responder certificate notAfter against the OCSP producedAt and thisUpdate timestamps.
Cross-reference accepted peer certificate serials against CRLs published by the issuing CA to identify revoked-but-accepted certificates.
Inventory Erlang/OTP deployments and identify hosts running public_key versions in the affected ranges.

Monitoring Recommendations

Enable ssl application logging at the debug or notice level on Erlang/OTP services that perform OCSP stapling validation and forward logs to a central SIEM.
Alert on TLS handshakes where the OCSP responder certificate validity window does not cover the response time.
Monitor outbound TLS connections from Erlang/OTP clients to high-risk endpoints and validate certificate revocation status out-of-band.

How to Mitigate CVE-2026-42791

Immediate Actions Required

Upgrade Erlang/OTP to 27.3.4.12, 28.5.0.1, or 29.0.1 — whichever matches the deployed major branch.
Audit all services that rely on public_key:pkix_ocsp_validate/5 or ssl OCSP stapling and prioritize those performing mTLS client authentication.
Coordinate with issuing CAs to confirm that delegated OCSP responder certificates have been rotated and that expired responder keys are retired and destroyed.

Patch Information

The Erlang/OTP team published fixes in commits 7995f1f and b3870e0. The patches add validity-period checks to pubkey_ocsp:verify_response/5 and pubkey_ocsp:is_authorized_responder/3. Refer to the OSV record EEF-CVE-2026-42791 for the full fixed-version matrix and the Erlang versions documentation for upgrade ordering semantics.

Workarounds

Disable OCSP stapling verification in the ssl application configuration where the trust model permits, and rely on CRL-based revocation checks instead.
Pin the set of acceptable OCSP responder certificates in application logic and reject responses signed by responders outside the pinned set.
Where mTLS is enforced, supplement OCSP with short-lived client certificates so that revocation exposure windows are minimized until upgrades complete.

bash

# Verify the installed public_key application version on an OTP node
erl -noshell -eval 'io:format("~p~n", [application:get_key(public_key, vsn)]), init:stop().'

# Example: ensure CRL checking is enabled as a defense-in-depth measure for ssl clients
# In sys.config or runtime ssl:connect/3 options:
# {verify, verify_peer},
# {crl_check, true},
# {crl_cache, {ssl_crl_cache, {internal, [{http, 5000}]}}}