GPU VulnDB

Database/Kernel, userspace & hypervisor

OpenSSL: memory leak per handshake when a server staples an OCSP response with no entries

CVE-2026-54876Kernel, userspace & hypervisorcurated

Impact

A TLS client that has explicitly enabled OCSP response checking leaks an OCSP_BASICRESP structure on every handshake against a server that staples a BasicOCSPResponse with an empty SingleResponse sequence. The leak size is attacker-tunable by padding the response with bogus certificates, so a long-running client that reconnects on a loop can be walked into memory exhaustion. This matters for fleet daemons that poll external endpoints continuously - registry pullers, telemetry shippers, license and entitlement clients on GPU nodes - because they are exactly the long-lived TLS clients that would be killed. OCSP response checking is off by default, so most deployments are not affected; check whether your clients set those verification flags before scheduling anything.

Who can reach it

A malicious or compromised TLS server that one of your clients connects to, where that client has enabled X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL. No authentication needed beyond getting the client to connect.

What to do

Patch OpenSSL per the 2026-08-05 advisory and restart the affected client daemons. First determine whether anything on the fleet actually enables the OCSP response check flags - if nothing does, this is a routine package update with no maintenance window. The FIPS modules in 3.6 and 4.0 are not affected.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.