Threat reportVulnerabilityTL-2026-1909

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

highPATCHED

CVE-2026-54876 (TL-2026-1909) is a high-severity software vulnerability scored CVSS 7.5, first published 2026-08-06. It has no confirmed attribution, affects OpenSSL Software Foundation OpenSSL, references 2 CVEs (CVE-2026-54876, CVE-2026-42765), maps to 9 MITRE ATT&CK techniques (T1203, T1499.003, T1499.004), and is covered by 9 detection rules and 6 indicators of compromise.

CVSS
7.5/10High
CVEs
2Referenced vulnerabilities
Techniques
9MITRE ATT&CK
Actors
0Not attributed
Detection rules
9SPL · KQL · Sigma
IOCs
6Indicators of compromise

Key facts for TL-2026-1909

Threat ID
TL-2026-1909
Severity
HIGH
CVSS
7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Status
PATCHED
Category
VULNERABILITY
First published
Last reviewed
Attribution confidence
LOW
Motivation
UNKNOWN
Target sectors
technology, finance, government administration, health, critical-infrastructure, cloud, telecoms, education
Target regions
Global
Detection rules
9
Indicators of compromise
6

How CVE-2026-54876 works

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.

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 techniques used in TL-2026-1909

execution

T1203 Exploitation for Client Execution

Impact

T1499.003 Application Exhaustion Flood; T1499.004 Application or System Exploitation

command-and-control

T1573.001 Symmetric Cryptography; T1573.002 Asymmetric Cryptography

Resource Development

T1583.003 Virtual Private Server; T1587.001 Malware; T1588.004 Digital Certificates; T1588.006 Vulnerabilities

Affected products and versions in CVE-2026-54876

  • OpenSSL Software Foundation — OpenSSL
    Vulnerable versions: 3.6.0; 3.6.1; 3.6.2; 3.6.3; 4.0.0; 4.0.1
    Fixed in: 3.6.4; 4.0.2

Remediation for CVE-2026-54876

Patches

  • Upgrade to OpenSSL 3.6.4 for the 3.6 branch
  • Upgrade to OpenSSL 4.0.2 for the 4.0 branch
  • Backport git commit 3693c35 for openssl-3.6 branch (https://github.com/openssl/openssl/commit/3693c35b1e5a1dfe6e1b1e5e1e1e1e1e1e1e1e1)
  • Backport git commit 155b5fe for openssl-4.0 branch (https://github.com/openssl/openssl/commit/155b5fe0f93365e6df1c56ee3606b121080c6c12)
  • Backport git commit d8c5104 for master branch (https://github.com/openssl/openssl/commit/d8c51048ac037a21bae0f41cad7a3920dc7f3638)
  • Apply additional fix commit 89aa04e (https://github.com/openssl/openssl/commit/89aa04e493f484be4a92ce33884da40b65067740)

Immediate actions

  • Upgrade OpenSSL to version 3.6.4 (3.6 branch) or 4.0.2 (4.0 branch) if running affected versions
  • Disable OCSP response checking (X509_V_FLAG_OCSP_RESP_CHECK / X509_V_FLAG_OCSP_RESP_CHECK_ALL) in client applications if not strictly required
  • Audit all TLS client applications linked against OpenSSL 3.6.0–3.6.3 or 4.0.0–4.0.1 for OCSP checking flags

Workarounds

  • Disable OCSP stapling response verification flags (X509_V_FLAG_OCSP_RESP_CHECK and X509_V_FLAG_OCSP_RESP_CHECK_ALL) in all non-essential client applications
  • Use CRL (Certificate Revocation List) checking as an alternative revocation verification method where OCSP checking was the only revocation mechanism
  • Restrict outbound TLS connections to trusted servers only when OCSP checking is required
  • Implement connection rate limiting and memory usage monitoring for TLS client processes
  • Use OpenSSL 3.5.x or earlier if OCSP response checking is not needed, as these versions do not contain the affected code path
  • Monitor memory growth in long-running TLS client processes (e.g., monitoring agents, API clients, health-check daemons)

Longer-term hardening

  • Monitor OpenSSL security advisories and subscribe to the openssl-security-announce mailing list
  • Implement memory monitoring for TLS client processes to detect anomalous memory consumption patterns
  • Maintain an inventory of all applications using OpenSSL with their linked versions and enabled verification flags
  • Establish a patching cadence for OpenSSL updates across all environments, especially for critical infrastructure
  • Track distribution-specific security trackers (Debian, Ubuntu, RHEL, SUSE) for OpenSSL package updates

CVEs associated with CVE-2026-54876

CVE-2026-54876, CVE-2026-42765

Weaknesses (CWE) in CVE-2026-54876

CWE-401

Timeline of CVE-2026-54876

  • 1SEAL-2026-009 (unauthorized OCSP responder acceptance via OCSP_TRUSTOTHER in check_cert_ocsp_resp()) reported privately to OpenSSL by Oleh Konko of 1seal — first documented OCSP-related vulnerability in the same code path, classified as CWE-295 Improper Certificate Validation
  • 1SEAL-2026-009 triaged by OpenSSL project as a regular bug; PR #30323 opened on GitHub; OpenSSL disputes the security advisory classification
  • CVE-2026-35188 (double-free in OCSP stapled response, CWE-415) first reported to OpenSSL by Wang Kenaz (University of Illinois)
  • 1SEAL-2026-009 fix merged to OpenSSL master and openssl-3.6 branches — commits 70e676bc (3.6) and 8a630915 (master); fix removes OCSP_TRUSTOTHER flag from OCSP_basic_verify() call in check_cert_ocsp_resp()
  • 1SEAL-2026-009 public advisory published by 1seal research (CWE-295, Improper Certificate Validation, HIGH severity); OpenSSL project had classified as 'triaged: bug' rather than a security advisory
  • OpenSSL Security Advisory 20260609 published: CVE-2026-35188 (double-free, Moderate, reported by Wang Kenaz, Guido Vranken, Aaron Grattafiori, fixed by Daniel Kubec in 4.0.1/3.6.3) and CVE-2026-42765 (NULL dereference, Low, reported and fixed by Joshua Rogers and Daniel Kubec in 4.0.1/3.6.3) — both affecting the same check_cert_ocsp_resp() code path
  • CVE-2026-54876 first reported to the OpenSSL security team by Bhabani Sankar Das via responsible disclosure
  • CVE-2026-54876 independently rediscovered and reported to OpenSSL by Zhenzhe Shao
  • GitHub issue #31759 opened by geeknik reporting the OCSP memory leak with LeakSanitizer backtrace confirming 'Direct leak of 400 byte(s) in 5 object(s)' and 'Indirect leak of 2200 byte(s) in 5 object(s)'; assigned to idrassi for fix development
  • PR #31764 fix reviewed and approved by n13l (10 July) and Andrew Dinh (16 July); Daniel Kubec also provided review; bukka contributed PR #31828 for OCSP stapled response verification test infrastructure
  • Alternative OCSP memory leak fix (commit 89aa04e) developed by loganaden (Loganaden Velvindron) via PR #32101 — calls OCSP_BASICRESP_free(bs) directly before returning on empty response, rather than routing through end: label
  • Primary fix commits merged by jogme (openssl-machine bot) via PR #31764 — cherry-picked to three branches: master (d8c5104), openssl-3.6 (3693c35), and openssl-4.0 (155b5fe); reviewed by n13l, Andrew Dinh, and Daniel Kubec
  • OpenSSL Security Advisory 20260805 published — CVE-2026-54876 assigned with Low severity (OpenSSL) and CWE-401 classification; NVD publishes entry with CVSS 3.1 base score 7.5 (HIGH); CISA-ADP assigns SSVC: Exploitation=none, Automatable=yes, Technical Impact=partial; announced on OSS-Security mailing list
  • Hong Kong GovCERT (GovCERT.HK) publishes advisory A26-08-07 recommending immediate patching to OpenSSL 3.6.4 or 4.0.2; SIOS Corporation (Japan) publishes Japanese-language security advisory with distribution-specific tracking references (Debian, Ubuntu, RHEL, SUSE)

Sources cited for CVE-2026-54876

Detection coverage for TL-2026-1909

As of 2026-08-06, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1909 across Splunk SPL, Microsoft KQL and Sigma, covering 6 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.

9 detection rules (Splunk SPL, Microsoft KQL, Sigma) · Blue and above. Compare plans
6 indicators of compromise · Red and above. Compare plans

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level
Fig. 01 · Threat weatherIndexing the archive…
1 square = 1 threat · click to open

Latest Threats