OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests

Eleven bytes will make an unpatched OpenSSL server set aside up to 131 KB of memory for a message that never arrives. On the glibc systems Okta tested, that memory is gone until the process restarts. OpenSSL shipped the HollowByte fix in June with no CVE, no advisory, and no changelog entry pointing at it. Okta's Red Team, which reported the denial-of-service bug and named it, published the

The article reports Okta Red Team’s disclosure of HollowByte, a denial-of-service flaw in OpenSSL where a malicious, unauthenticated TLS handshake as small as 11 bytes can cause the server to reserve up to roughly 131 KB of memory per connection and block worker threads, leading to sustained memory loss until the process restarts on glibc systems.[1][2][3][6] OpenSSL quietly fixed this behavior as a “bug or hardening” change in versions 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21, without a CVE or prominent advisory, by only growing buffers when data arrives instead of trusting attacker-controlled length headers.[1][2][3] From a RealGround perspective, this highlights AI supply chain risk: AI systems and agents that rely on OpenSSL for TLS could suffer availability outages or degraded performance if libraries are not tracked and patched promptly, so organizations should maintain SBOMs that include OpenSSL versions for all AI services, enforce rapid patch SLAs, and continuously red-team AI infrastructure for low-bandwidth DoS vectors tied to underlying cryptographic dependencies.[3][4]