CVE-2026-54876

What it actually does

This is an availability vulnerability in TLS client-side certificate verification when OpenSSL OCSP response checking is explicitly enabled with X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL. A malicious TLS server can staple a BasicOCSPResponse that contains an empty SEQUENCE OF SingleResponse entries. OpenSSL accepts and parses the response, but an early return path fails to free the OCSP_BASICRESP structure allocated by OCSP_response_get1_basic(). The attacker can increase the amount of leaked memory per TLS handshake by padding the OCSP response certs field with bogus certificates that are parsed and retained in the leaked structure. Repeated handshakes can exhaust memory in long-running TLS client processes. Confidentiality and integrity are not directly affected. OCSP response checking is not enabled by default, and the OpenSSL FIPS modules in 4.0 and 3.6 are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Organizations running long-lived TLS clients that explicitly validate stapled OCSP responses could experience process crashes, degraded service, failed outbound integrations, job failures, monitoring outages, or broader application downtime if those clients repeatedly connect to a malicious or compromised TLS server. The vulnerability is remotely reachable, requires no authentication or user interaction, and has a high availability impact, but current exploitation indicators are low: EPSS is 0.00261, no public exploit maturity is reported, and it is not listed in CISA KEV or known ransomware use. Because the issue was recently published, security teams should still prioritize exposure review for internet-facing crawlers, scanners, webhook processors, package fetchers, API clients, and other systems that connect to arbitrary or third-party TLS endpoints.

How an attack unfolds

An attacker operates or compromises a TLS server and configures it to provide a malformed but syntactically accepted stapled OCSP response during the TLS handshake. The response contains a BasicOCSPResponse with no SingleResponse entries, and may include many bogus certificates in the certs field to increase memory consumption. A vulnerable client application must have explicitly enabled OpenSSL OCSP response checking. When the client connects, OpenSSL parses the OCSP response during X.509 chain verification, allocates internal structures, reaches the empty-response validation path, and returns before releasing the allocated OCSP_BASICRESP object. A single connection leaks memory; repeated connections to the malicious server gradually increase the client process memory footprint. In long-running services, automated polling, retries, crawlers, or queued jobs can turn this into sustained memory exhaustion and denial of service.

How to fix it

Upgrade OpenSSL and any statically linked or bundled applications to vendor-provided fixed releases as soon as they are available; no exact fixed versions were provided in the input, so track the relevant OpenSSL and operating-system package advisories for CVE-2026-54876. Prioritize systems that run long-lived TLS clients and explicitly enable OCSP response checking with X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL. If immediate patching is not possible, consider temporarily disabling OCSP stapled response checking where business risk permits, especially for clients that connect to untrusted or user-supplied TLS endpoints. Reduce exposure by restricting outbound TLS connections to trusted destinations, limiting redirects to untrusted hosts, enforcing connection and retry limits, and applying memory limits or process supervision to affected services. Restart vulnerable long-running clients after mitigation to clear leaked memory. The OpenSSL FIPS modules in 4.0 and 3.6 do not require remediation for this issue, but applications outside the FIPS boundary may still need updates.

How to confirm the fix worked

Confirm whether deployed applications use an affected OpenSSL build and explicitly enable OCSP response checking flags. Review source code, configuration, and dependency manifests for X509_V_FLAG_OCSP_RESP_CHECK, X509_V_FLAG_OCSP_RESP_CHECK_ALL, SSL_set_tlsext_status_type, OCSP_response_get1_basic, or application-specific OCSP stapling validation settings. Verify package manager output, container images, SBOMs, and statically linked binaries against vendor fixed versions once released. Test representative clients against a controlled TLS server that staples an empty-response OCSP BasicOCSPResponse and monitor whether process memory remains stable across repeated handshakes after the fix. Validate that outbound TLS clients either no longer use the vulnerable OpenSSL version or no longer enable the affected OCSP verification path. Also confirm operational safeguards such as retry limits, destination allowlists, and memory limits are active for services that connect to untrusted TLS endpoints.

Typical attack path

1. Identify or wait for a TLS client that connects to attacker-controlled or attacker-influenced HTTPS/TLS endpoints.
2. Configure a malicious TLS server to staple an OCSP BasicOCSPResponse containing an empty SingleResponse sequence.
3. Optionally pad the OCSP response certs field with bogus certificates to amplify the memory leaked per handshake.
4. Trigger repeated client connections through normal application behavior, redirects, retries, scheduled polling, webhook delivery, crawling, or user-supplied URLs.
5. Each handshake causes the vulnerable OpenSSL verification path to leak memory in the client process.
6. Continue until the client slows down, is killed by the operating system or process supervisor, or becomes unavailable due to memory exhaustion.

How to detect it

Retrospective detection should focus on evidence of unexplained memory growth or out-of-memory termination in TLS client processes that connect to external servers while OCSP response checking is enabled. Review operating-system logs, container runtime events, systemd or supervisor logs, application logs, EDR telemetry, and network/proxy logs. Look for long-running client processes with steadily increasing resident memory size after repeated TLS handshakes to the same remote endpoint, followed by restart, crash, or OOM kill events. Correlate these events with outbound TLS connections to newly observed, untrusted, user-supplied, or unusual domains/IP addresses. Network inspection, where available and lawful, should look for TLS handshakes using the status_request extension and stapled OCSP responses whose BasicOCSPResponse has an empty SingleResponse sequence, especially when the response includes an unusually large certs field. Application logs may not contain a clear OpenSSL error because the issue is a memory leak rather than a clean validation failure, so absence of explicit certificate errors does not rule out exploitation.

• X509_V_FLAG_OCSP_RESP_CHECK
• X509_V_FLAG_OCSP_RESP_CHECK_ALL
• OCSP_response_get1_basic
• SSL_set_tlsext_status_type
• oom-killer
• Out of memory: Killed process
• Killed process
• Memory cgroup out of memory
• container killed due to memory limit
• TLS status_request
• BasicOCSPResponse
• SingleResponse
• OCSP stapling

What your security team should do

• Inventory TLS client applications and services that use OpenSSL and connect to third-party, arbitrary, or user-supplied TLS endpoints.
• Prioritize review of long-running processes, crawlers, scanners, webhook handlers, package/download clients, monitoring systems, and API integrations that may repeatedly connect to the same remote server.
• Determine whether OCSP response checking is explicitly enabled through X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL; systems without those flags are not affected by the described vulnerable path.
• Track OpenSSL, operating-system, container base image, and application vendor advisories for fixed versions, then patch or rebuild affected assets promptly.
• Where patching is delayed, disable OCSP stapled response checking if acceptable, or restrict outbound TLS destinations to trusted allowlists.
• Add monitoring for abnormal memory growth in TLS client processes, repeated connections to the same external TLS endpoint before memory exhaustion, and operating-system OOM killer events.
• Use process supervisors, memory limits, and backoff policies to reduce the blast radius of memory exhaustion in long-running services.
• Because there is no KEV listing, no known ransomware use, low EPSS, and no reported exploit maturity, treat this as targeted availability risk rather than broad active exploitation, while still addressing exposed high-dependency clients.