CVE-2026-54876 in OpenSSL
Summary
by MITRE • 08/05/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/06/2026
This vulnerability represents a critical memory management flaw in OpenSSL's certificate verification process that aligns with CWE-401, specifically missing release of memory after effective lifetime. The issue manifests when TLS clients perform OCSP response checking, a security mechanism designed to validate certificate revocation status in real-time. When an attacker-controlled TLS server sends an OCSP response containing no single response entries within the BasicOCSPResponse structure, the OpenSSL library fails to properly clean up allocated memory resources. This occurs because the code path includes an early return statement that bypasses the standard cleanup routines, leaving memory allocated in the OCSP_BASICRESP structure unreleased.
The technical exploitation of this vulnerability leverages the fact that while empty SEQUENCE OF SingleResponse entries are technically valid according to ASN.1 encoding rules and accepted by OpenSSL's decoder, the subsequent code flow does not account for this scenario properly. The affected function executes during X.509 certificate chain verification when either X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL verification flags are active, typically occurring in TLS client applications that verify OCSP responses stapled into TLS handshakes by servers. This behavior creates a memory leak where each vulnerable handshake consumes additional memory that is never freed, effectively allowing for a gradual accumulation of leaked memory over time.
The operational impact extends beyond simple resource consumption to potential system instability and denial of service conditions. The vulnerability operates through the ATT&CK technique T1499.004, specifically targeting resource exhaustion by consuming available memory. An attacker can amplify the memory leak by padding the certs field of the BasicOCSPResponse with additional bogus certificates, which are parsed and stored in the structure before the empty response check triggers the early return. This amplification factor means that each connection attempt consumes increasingly larger amounts of memory, making the attack more effective. Long-running client applications that repeatedly establish connections to a malicious server will experience progressive memory exhaustion until system resources are depleted.
The vulnerability affects only client applications that explicitly enable OCSP response checking through verification flags, as OCSP validation is not enabled by default in OpenSSL implementations. This selective exposure means that the attack surface is limited to specific configurations but remains significant given that many security-sensitive applications implement explicit OCSP checking. The FIPS modules in versions 4.0 and 3.6 are unaffected because the problematic code exists outside the FIPS module boundary, indicating that the vulnerability resides in standard OpenSSL components rather than FIPS-certified cryptographic implementations. The memory leak occurs during the certificate verification phase of TLS handshakes, making it particularly dangerous in high-volume applications such as web browsers, email clients, or any system maintaining persistent connections to potentially malicious servers.
Mitigation strategies should focus on immediate software updates from OpenSSL maintainers to patch the memory management issue, while also implementing connection rate limiting and monitoring for abnormal memory consumption patterns. Applications should consider disabling OCSP checking when connecting to untrusted servers or when operating in environments where such attacks are possible. The vulnerability demonstrates a classic example of how seemingly benign protocol elements can create security issues when combined with improper resource management practices, highlighting the importance of comprehensive testing and validation of edge cases in cryptographic libraries.