CVE-2026-54876: OpenSSL TLS Client DoS Vulnerability

CVE-2026-54876 Overview

CVE-2026-54876 is a memory leak vulnerability in OpenSSL affecting TLS clients that enable Online Certificate Status Protocol (OCSP) response checking. A malicious TLS server can send a BasicOCSPResponse containing an empty SEQUENCE OF SingleResponse to trigger the leak during X.509 certificate chain verification. The OCSP_BASICRESP structure allocated by OCSP_response_get1_basic() is not freed because an early return bypasses cleanup code. Attackers can amplify leaked memory per handshake by padding the certs field with bogus certificates. A long-running TLS client repeatedly connecting to a malicious server can exhaust memory, resulting in denial of service. The issue is classified as [CWE-401] Missing Release of Memory after Effective Lifetime.

Critical Impact
A remote malicious TLS server can force memory exhaustion in a long-running TLS client, causing denial of service in applications that explicitly enable X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags.

Affected Products

OpenSSL client applications with OCSP response checking explicitly enabled
TLS clients using X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags
Note: OpenSSL FIPS modules in 4.0 and 3.6 are not affected as the vulnerable code is outside the FIPS module boundary

Discovery Timeline

2026-08-05 - CVE-2026-54876 published to NVD
2026-08-05 - OpenSSL Security Advisory released
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-54876

Vulnerability Analysis

The vulnerability resides in the OCSP response verification path within crypto/x509/x509_vfy.c. During X.509 certificate chain verification with OCSP response checking enabled, OpenSSL calls OCSP_response_get1_basic() to obtain an owning reference to a BasicOCSPResponse structure. The code then checks whether the response contains at least one SingleResponse entry using OCSP_resp_count(bs). When the count is less than one, the function returns X509_V_ERR_OCSP_NO_RESPONSE directly, bypassing the end: cleanup label that frees bs.

An empty SEQUENCE OF SingleResponse is permitted on the wire and accepted by the OpenSSL ASN.1 decoder. This creates a leak of the entire OCSP_BASICRESP structure on every affected handshake. OCSP response checking is not enabled by default, so only applications that explicitly set the OCSP verification flags are affected.

Root Cause

The root cause is a missing goto to the cleanup label. OCSP_response_get1_basic() returns an owning reference that must be released through the end: cleanup path. The original code combined the NULL check for bs and the OCSP_resp_count(bs) < 1 check into a single conditional that returned directly, leaking bs when it was non-NULL but empty. Attackers amplify the leak size by padding the certs field with bogus certificates that are parsed and stored within the leaked structure before the empty response check fires.

Attack Vector

A malicious TLS server staples a crafted OCSP response into the TLS handshake. The response is well-formed but contains zero SingleResponse entries and an arbitrarily large certs array. Each handshake leaks a tunable amount of memory. A victim client that reconnects repeatedly (for example, a monitoring agent, proxy, or long-running application) accumulates leaked memory until the process is killed or the host becomes unresponsive.

         return X509_V_ERR_OCSP_NO_RESPONSE;
 
     if ((resp = sk_OCSP_RESPONSE_value(ctx->ocsp_resp, ctx->error_depth)) == NULL
-        || (bs = OCSP_response_get1_basic(resp)) == NULL
-        || (num = OCSP_resp_count(bs)) < 1)
+        || (bs = OCSP_response_get1_basic(resp)) == NULL)
         return X509_V_ERR_OCSP_NO_RESPONSE;
 
+    /*
+     * OCSP_response_get1_basic() returns an owning reference, so once bs is
+     * non-NULL it must be released via the end: cleanup label. Route an empty
+     * BasicResponse (no single responses) through end: rather than returning
+     * directly, otherwise bs leaks.
+     */
+    if ((num = OCSP_resp_count(bs)) < 1) {
+        ret = X509_V_ERR_OCSP_NO_RESPONSE;
+        goto end;
+    }
+
     if (OCSP_response_status(resp) != OCSP_RESPONSE_STATUS_SUCCESSFUL) {
         OCSP_BASICRESP_free(bs);
         bs = NULL;

Source: GitHub OpenSSL Commit Fix

Detection Methods for CVE-2026-54876

Indicators of Compromise

Progressive resident set size (RSS) growth in TLS client processes that perform OCSP validation, correlated with outbound TLS handshakes to a single remote endpoint
OCSP responses in captured TLS handshakes where the BasicOCSPResponse contains zero SingleResponse entries but a populated certs field
Repeated TLS reconnections from a client to the same server with no successful certificate status result

Detection Strategies

Inventory applications that link against affected OpenSSL versions and grep source or configuration for X509_V_FLAG_OCSP_RESP_CHECK and X509_V_FLAG_OCSP_RESP_CHECK_ALL usage
Inspect TLS traffic with a decoder capable of parsing stapled OCSP responses and flag responses with an empty responses sequence
Monitor per-process memory growth trends for TLS-enabled services and alert on sustained upward slope without corresponding workload increase

Monitoring Recommendations

Collect process memory metrics from Linux cgroups and Windows performance counters for services that terminate or initiate TLS with OCSP verification enabled
Log OpenSSL error stack entries containing X509_V_ERR_OCSP_NO_RESPONSE and correlate frequency by destination host
Track outbound TLS session counts to unfamiliar external endpoints from server workloads that historically have stable connection patterns

How to Mitigate CVE-2026-54876

Immediate Actions Required

Upgrade OpenSSL to the fixed versions referenced in the OpenSSL Security Advisory 2026
Identify all applications that explicitly enable OCSP response checking through X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL and prioritize their patching
Restart long-running TLS client processes after patching to release any previously leaked memory

Patch Information

The fix routes the empty-response case through the existing end: cleanup label so OCSP_BASICRESP_free() releases the structure. Apply the upstream patches from commits 155b5fe0 and d8c51048, or install vendor-supplied packages that incorporate these commits. FIPS modules in OpenSSL 4.0 and 3.6 do not require the patch as the affected code lies outside the FIPS module boundary.

Workarounds

Disable OCSP response checking by clearing X509_V_FLAG_OCSP_RESP_CHECK and X509_V_FLAG_OCSP_RESP_CHECK_ALL where certificate revocation can be enforced through alternative mechanisms such as CRL distribution points
Restrict outbound TLS destinations for long-running clients to trusted servers using egress firewall rules until the patch is deployed
Apply process resource limits (RLIMIT_AS, systemd MemoryMax) so exhaustion terminates and restarts the process rather than degrading the host

bash

# Verify installed OpenSSL version and rebuild affected services
openssl version -a

# Example systemd hardening to cap memory of a TLS client service
# /etc/systemd/system/myservice.service.d/limits.conf
[Service]
MemoryMax=512M
Restart=on-failure