# CVE-2026-54876 — OpenSSL Client-Side Memory Leak in OCSP Response Checking (Denial of Service)

> A malicious TLS server can trigger a memory leak in TLS clients that have enabled OCSP response checking (CVE-2026-54876). The vulnerability affects OpenSSL 3.6.0 through 3.6.3 and 4.0.0 through 4.0.1. An attacker-controlled TLS server sends an OCSP stapled response containing an empty SEQUENCE OF SingleResponse, causing the OCSP_BASICRESP structure allocated by OCSP_response_get1_basic() to never be freed due to a missing cleanup path. The leak can be amplified by padding the certs field with bogus certificates, enabling attacker-tunable memory exhaustion. Patches are available in OpenSSL 3.6.4 and 4.0.2.

- **Published:** 2026-08-06T00:00:00Z
- **Last reviewed:** 2026-08-06T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-1909
- **ID:** TL-2026-1909
- **Severity:** HIGH (CVSS 7.5)
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 · **IOCs:** 6 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-54876, CVE-2026-42765

## Description

CVE-2026-54876 is a client-side memory leak vulnerability in OpenSSL's OCSP response checking code, discovered independently by Bhabani Sankar Das (15 June 2026) and Zhenzhe Shao (19 June 2026), with the primary fix developed by Mounir Idrassi and merged via GitHub PR #31764. The OpenSSL project rates the severity as Low, while the CISA-ADP assigns a CVSS 3.1 base score of 7.5 (HIGH) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, reflecting the network-based, low-complexity nature of the attack despite the requirement for OCSP checking to be explicitly enabled.

Root Cause: The bug resides in the check_cert_ocsp_resp() function in crypto/x509/x509_vfy.c (lines 1194-1207 in the 3.6 branch, lines 1304-1317 in the 4.0 branch). When a TLS client with OCSP response checking enabled receives a BasicOCSPResponse containing an empty SEQUENCE OF SingleResponse — which is permitted on the wire and accepted by the decoder — the OCSP_BASICRESP structure allocated by OCSP_response_get1_basic() is never freed. The original code used a combined boolean check: if ((resp = ...) == NULL || (bs = OCSP_response_get1_basic(resp)) == NULL || (num = OCSP_resp_count(bs)) < 1) return X509_V_ERR_OCSP_NO_RESPONSE; — the early return when OCSP_resp_count(bs) < 1 bypassed the end: cleanup label where OCSP_BASICRESP_free(bs) would have been called. The CWE-401 classification (Missing Release of Memory after Effective Lifetime) captures this precisely: the owning reference returned by OCSP_response_get1_basic() is leaked because the function returns before reaching the cleanup code.

LeakSanitizer evidence from the fix (GitHub issue #31759, reported by geeknik on 28 June 2026) confirms the backtrace: CRYPTO_malloc (crypto/mem.c:214) → OCSP_response_get1_basic (crypto/ocsp/ocsp_cl.c:128) → check_cert_ocsp_resp (crypto/x509/x509_vfy.c:1298) → check_revocation (crypto/x509/x509_vfy.c:1207) → X509_verify_cert (crypto/x509/x509_vfy.c:313). The issue reports 'Direct leak of 400 byte(s) in 5 object(s)' and 'Indirect leak of 2200 byte(s) in 5 object(s)' per test iteration, with the test using X509_verify_cert with X509_V_FLAG_OCSP_RESP_CHECK and an empty-BasicResponse staple.

Amplification: An attacker can significantly amplify the memory leaked per handshake by padding the certs field of the BasicOCSPResponse with bogus certificates. These certificates are parsed and stored in the leaked OCSP_BASICRESP structure before the empty-response check triggers the early return, making the per-handshake leak attacker-tunable and proportional to the number and size of bogus certificates included. A long-running TLS client that repeatedly connects to a malicious server can experience progressive memory exhaustion, leading to denial of service.

Attack Vector: The vulnerability is reachable via TLS 1.3 status_request (OCSP stapling) extension, where the server staples a crafted OCSP response into the Certificate message of the TLS handshake. In TLS 1.3, the Certificate message is encrypted following the key exchange, meaning the malicious OCSP response is delivered over an encrypted channel. The vulnerable function is invoked during X.509 certificate chain verification when either X509_V_FLAG_OCSP_RESP_CHECK (leaf certificate OCSP checking) or X509_V_FLAG_OCSP_RESP_CHECK_ALL (full chain OCSP checking) is enabled.

Mitigating Factors: (1) OCSP response checking is NOT enabled by default — only client applications that explicitly enable these verification flags are affected. (2) The FIPS modules in OpenSSL 3.6 and 4.0 are not affected; the vulnerable code is outside the FIPS module boundary. (3) The vulnerability only affects OpenSSL 3.6.x and 4.0.x — the check_cert_ocsp_resp() function was introduced in these branches. (4) CISA SSVC assessment rates exploitation as 'none' with the vulnerability not appearing on the CISA KEV list.

Fix and Patch History: The primary fix (PR #31764, authored by Mounir Idrassi) was opened in late June 2026 after geeknik's issue report. The fix was reviewed by n13l (approved 10 July 2026) and Andrew Dinh (approved 16 July 2026), with additional review from Daniel Kubec. The PR was merged on 3 August 2026 by jogme (openssl-machine bot). The fix was cherry-picked to three branches: master (commit d8c5104), openssl-3.6 (commit 3693c35), and openssl-4.0 (commit 155b5fe). The fix separates the OCSP_resp_count() check from the combined acquisition condition: if ((num = OCSP_resp_count(bs)) < 1) { ret = X509_V_ERR_OCSP_NO_RESPONSE; goto end; } — routing through the end: cleanup label so OCSP_BASICRESP_free(bs) is always called. A separate fix (commit 89aa04e by loganaden via PR #32101, 28 July 2026) takes an alternative approach by calling OCSP_BASICRESP_free(bs) directly before returning. Test infrastructure was contributed by bukka via PR #31828, which adds OCSP stapled response verification tests. The OpenSSL advisory states that no new releases would be issued at the time of publication due to the Low severity, with the fix to be included in the next releases of the 4.0 and 3.6 branches.

Related OCSP Vulnerabilities in the Same Code Path: This CVE is part of a broader pattern of issues in the check_cert_ocsp_resp() code path in OpenSSL 3.6/4.0. CVE-2026-35188 (Moderate, June 2026 advisory) is a double-free (CWE-415) triggered by a crafted OCSP stapled response in TLS client certificate verification, reported independently by Wang Kenaz (University of Illinois, 17 March), Guido Vranken (Aisle Research, 26 March), and Aaron Grattafiori (Nvidia, 30 March), with the fix developed by Daniel Kubec. CVE-2026-42765 (Low, June 2026 advisory) is a NULL pointer dereference (CWE-476) when X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL are both enabled and the chain lacks a self-signed trusted anchor, reported and fixed by Joshua Rogers (Aisle Research) with Daniel Kubec. Additionally, 1SEAL-2026-009 (March 2026, HIGH severity, CWE-295) found that check_cert_ocsp_resp() accepted unauthorized OCSP responses signed by any certificate from the peer-provided chain — including the leaf certificate itself — because OCSP_basic_verify() was called with the OCSP_TRUSTOTHER flag enabled, collapsing the boundary between the certificate being validated and the authority allowed to attest to its revocation status. This issue was discovered by Oleh Konko of 1seal (reported 14 February 2026, fix merged 21 March 2026). All three coexisting vulnerabilities (CVE-2026-54876, CVE-2026-35188, CVE-2026-42765) and the 1SEAL finding share the same check_cert_ocsp_resp() function and affect the same OpenSSL branches.

No evidence of active exploitation in the wild has been identified as of the advisory date. CISA KEV does not list this CVE, and the SSVC assessment reports 'Exploitation: none'. The CISA-ADP SSVC evaluation additionally notes 'Automatable: yes' and 'Technical Impact: partial'.

## MITRE ATT&CK

- T1587.001 Malware
- T1588.004 Digital Certificates
- T1588.006 Vulnerabilities
- T1583.003 Virtual Private Server
- T1203 Exploitation for Client Execution
- T1573.001 Symmetric Cryptography
- T1573.002 Asymmetric Cryptography
- T1499.003 Application Exhaustion Flood
- T1499.004 Application or System Exploitation

## Sources

- [OpenSSL Security Advisory 20260805 — CVE-2026-54876](https://openssl-library.org/news/secadv/20260805.txt)
- [HKCERT Advisory A26-08-07 — OpenSSL Vulnerability](https://www.govcert.gov.hk/en/alerts_detail.php?id=2000)
- [NVD Entry — CVE-2026-54876 (CVSS 7.5 HIGH)](https://nvd.nist.gov/vuln/detail/CVE-2026-54876)
- [MITRE CVE Record — CVE-2026-54876](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-54876)
- [GitHub Issue #31759 — Memory Leak in OCSP Multi-Stapling Verify Check (geeknik)](https://github.com/openssl/openssl/issues/31759)
- [GitHub PR #31764 — Main Fix for OCSP BasicResponse Leak (Mounir Idrassi)](https://github.com/openssl/openssl/pull/31764)
- [GitHub Commit 155b5fe — 4.0 Branch Fix (Mounir Idrassi)](https://github.com/openssl/openssl/commit/155b5fe0f93365e6df1c56ee3606b121080c6c12)
- [GitHub Commit d8c5104 — Master Branch Fix (Mounir Idrassi)](https://github.com/openssl/openssl/commit/d8c51048ac037a21bae0f41cad7a3920dc7f3638)
- [GitHub Commit 89aa04e — Alternative OCSP Memory Leak Fix (loganaden)](https://github.com/openssl/openssl/commit/89aa04e493f484be4a92ce33884da40b65067740)
- [GitHub PR #32101 — Additional OCSP Memory Leak Fix (loganaden)](https://github.com/openssl/openssl/pull/32101)
- [OSS-Security Mailing List — CVE-2026-54876 Announcement](https://www.openwall.com/lists/oss-security/2026/08/05/8)
- [OpenSSL Vulnerabilities Page (2026 Advisory List)](https://openssl-library.org/news/vulnerabilities/)
- [1SEAL-2026-009 — OpenSSL 3.6 Stapled OCSP Verification Vulnerability](https://1seal.org/research/advisories/1SEAL-2026-009/)
- [OpenSSL Security Advisory 20260609 — CVE-2026-35188 / CVE-2026-42765 (Related OCSP CVEs)](https://openssl-library.org/news/secadv/20260609.txt)
- [NVD Entry — CVE-2026-35188 (Double-Free in OCSP Stapling, Moderate)](https://nvd.nist.gov/vuln/detail/CVE-2026-35188)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-1909