CVE-2026-54876 is a high-severity (CVSS 7.5) CWE-401 vulnerability. A fix is available — see the affected versions and patch details below.
Client-Side Memory Leak in OCSP Response Checking
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54876.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Description
Issue summary: A malicious TLS server can cause a memory leak in a TLS client that has enabled OCSP response checking by sending an OCSP response that contains no single response entries.
Impact summary: An attacker can leak an attacker-tunable amount of memory per TLS handshake in a victim client application. A long-running client that repeatedly connects to a malicious server can have its memory exhausted, resulting in a Denial of Service.
CWE: CWE-401: Missing Release of Memory after Effective Lifetime
Description: The affected function is called during X.509 certificate chain verification when OCSP response checking is enabled with the X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags, for example when a TLS client verifies an OCSP response stapled into the TLS handshake by the server.
When the received BasicOCSPResponse contains an empty SEQUENCE OF SingleResponse, which is permitted on the wire and accepted by the OpenSSL decoder, the OCSP_BASICRESP structure allocated by OCSP_response_get1_basic() was not freed because an early return bypassed the cleanup code at the end of the function.
The amount of memory leaked per handshake can be amplified by the attacker 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 triggers the early return. A long-running TLS client that repeatedly connects to a malicious server can have its memory exhausted over time.
OCSP response checking is not enabled by default. Only client applications that explicitly enable the OCSP response check verification flags are affected.
FIPS impact: no
The FIPS modules in 4.0 and 3.6 are not affected by this issue as the affected code is outside the OpenSSL FIPS module boundary.
Detection & mitigation playbook
VulnerabilityDetect
Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).
Fix
Upgrade the affected component to the fixed release for CVE-2026-54876, or apply your distribution's backported patch — distro builds are often patched at an older version number, so check your vendor's advisory rather than the upstream version alone.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
This vulnerability is rated Important because a malicious TLS server can cause memory exhaustion and denial of service in a long-running client. Exploitation requires the client application to enable OCSP response checking and process a crafted OCSP response from the server. Exposure therefore depends on the…
No broadly applicable mitigation is available. If an affected client application provides a configuration setting for OCSP response checking, operators can temporarily disable it where their certificate revocation policy permits. This blocks the vulnerable response-checking path but removes OCSP-based revocation checks. Clients that must keep OCSP response checking enabled remain exposed.Source: Red Hat security advisory for CVE-2026-54876 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | chunkah-main-0.6.0-3.hum1 | RHSA-2026:42825 |
| Red Hat Hardened Images | python-cryptography-main-50.0.0-1.hum1 | RHSA-2026:55543 |
| Red Hat Hardened Images | openssl-main-3.5.6-0.5.hum1 | RHSA-2026:56097 |
| Red Hat Hardened Images | openssl3-main-3.5.7-2.2.hum1 | RHSA-2026:57021 |
| Red Hat Hardened Images | ruby4-0-main-4.0.6-37.2.hum1 | RHSA-2026:57565 |
| Red Hat Hardened Images | ruby3-3-main-3.3.10-23.5.hum1 | RHSA-2026:57986 |
| Red Hat Hardened Images | ruby3-4-main-3.4.10-31.6.hum1 | RHSA-2026:57994 |
| Red Hat Satellite 6.18 | satellite/iop-vmaas-rhel9:1789611858 | RHSA-2026:68764 |
Frequently Asked Questions
Is CVE-2026-54876 in your dependencies?
Find it across your dependency tree, including transitive dependencies.