CVE-2026-54876: 
OpenSSL vulnerability analysis and mitigation

CVE-2026-54876 is a client-side memory leak vulnerability in OpenSSL's OCSP response checking logic, classified as "Client-Side Memory Leak in OCSP Response Checking." A malicious TLS server can trigger the leak by sending a BasicOCSPResponse containing an empty SEQUENCE OF SingleResponse, causing the OCSP_BASICRESP structure to be allocated but never freed. Affected versions are OpenSSL 4.0.0–4.0.1 (fixed in 4.0.2) and OpenSSL 3.6.0–3.6.3 (fixed in 3.6.4); versions 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 are not affected. The vulnerability was reported on June 15, 2026 by Bhabani Sankar Das and independently on June 19, 2026 by Zhenzhe Shao, and publicly disclosed on August 5, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, oss-security).

The root cause is CWE-401 (Missing Release of Memory after Effective Lifetime) in the check_cert_ocsp_resp() function within crypto/x509/x509_vfy.c. When OCSP_response_get1_basic() successfully allocates an OCSP_BASICRESP structure (bs) and the subsequent OCSP_resp_count(bs) < 1 check triggers an early return, the cleanup label (end:) is bypassed, leaking the allocated memory. An attacker can amplify the leak by padding the certs field of the BasicOCSPResponse with bogus certificates, which are parsed and stored in the leaked structure before the empty-response check fires. Exploitation requires the victim client to have explicitly enabled X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL — these flags are not enabled by default. The fix, developed by Mounir Idrassi, separates the count check from the acquisition and routes the empty-response case through the end: label via goto, ensuring bs is always freed (oss-security, OpenSSL commit 155b5fe, OpenSSL commit d8c5104).

The sole impact is availability: an unauthenticated network attacker controlling a TLS server can cause a memory leak of an attacker-tunable size per TLS handshake in any connecting client that has OCSP response checking enabled. Over time, a long-running client repeatedly connecting to the malicious server will exhaust its memory, resulting in a Denial of Service. There is no confidentiality or integrity impact, and the OpenSSL FIPS modules in versions 4.0 and 3.6 are not affected since the vulnerable code lies outside the FIPS module boundary (GitHub Advisory, oss-security).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The NVD SSVC assessment classifies exploitation as "none" and technical impact as "partial." The EPSS score is approximately 0.261% (18th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is automatable (no user interaction required) but is limited to clients that have explicitly opted into non-default OCSP checking flags, significantly narrowing the attack surface (GitHub Advisory).

1. Set up a malicious TLS server: Configure a server to staple a crafted OCSP response during the TLS handshake. The crafted BasicOCSPResponse must contain an empty SEQUENCE OF SingleResponse (zero entries), which is valid on the wire and accepted by the OpenSSL decoder.
2. Amplify memory leak (optional): Pad the certs field of the BasicOCSPResponse with bogus certificates. These are parsed and stored in the OCSP_BASICRESP structure before the empty-response check triggers the early return, increasing the amount of memory leaked per handshake.
3. Attract victim connections: Lure or position the malicious server such that a long-running TLS client application with X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL enabled repeatedly connects to it (e.g., via DNS poisoning, BGP hijacking, or a man-in-the-middle position).
4. Exhaust client memory: Each TLS handshake leaks the unfreed OCSP_BASICRESP structure. Over many repeated connections, the victim client's memory is progressively exhausted, eventually causing a Denial of Service (oss-security, OpenSSL commit 155b5fe).

• Network: Repeated TLS connections from a client to an unusual or unexpected server endpoint; TLS handshakes that complete but result in no meaningful application-layer traffic (server stapling malformed OCSP responses).
• Process/Memory: Steadily increasing memory consumption in a TLS client process over time without a corresponding increase in workload; out-of-memory (OOM) kills of TLS client processes.
• Logs: OpenSSL error log entries referencing X509_V_ERR_OCSP_NO_RESPONSE in conjunction with high connection rates to a single server; system logs showing OOM events or process crashes in applications using OpenSSL with OCSP checking enabled.

OpenSSL users should upgrade to OpenSSL 4.0.2 (for 4.0.x users) or OpenSSL 3.6.4 (for 3.6.x users) once these releases become available; the fixes are already present in commits d8c5104 (4.0 branch) and 155b5fe (3.6 branch) in the OpenSSL git repository. As an immediate workaround, disable OCSP response checking by removing the X509_V_FLAG_OCSP_RESP_CHECK and X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags if they are not strictly required. Additionally, implement connection rate limits and memory usage monitoring on TLS client applications to detect and mitigate potential memory exhaustion. OpenSSL 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 are not affected and require no action (oss-security, GitHub Advisory).

The OpenSSL project classified this issue as Low severity in its own security policy, noting that OCSP response checking is not enabled by default and the fix will be included in the next scheduled releases rather than an emergency patch (oss-security). The vulnerability was reported by security researcher geeknik on GitHub, who also suggested the fix approach adopted by the OpenSSL team (OpenSSL commit 155b5fe). Community discussion on oss-security and Bluesky/Mastodon was limited, consistent with the low-severity, non-default-configuration nature of the issue.