Eleven bytes. That's all it takes to make an unpatched OpenSSL server set aside up to 131 KB of memory for a message that never arrives. On systems running glibc, that memory stays locked up until the process restarts.
Okta's Red Team discovered the flaw, named it HollowByte, and published the details on Thursday. OpenSSL shipped the fix in June without a CVE, without an advisory, and with no changelog entry pointing at it. The fixed releases are OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21, all dated June 9.
The Flaw: Trusting the Attacker's Word
Every TLS handshake message carries a 4-byte header. Three of those bytes declare the size of the body that follows. Older OpenSSL versions grew the receive buffer to that declared size the moment the header landed before a single byte of the body showed up and before the handshake's own validation checks ran.
For an inbound ClientHello, the ceiling is 131 KB. The worker thread blocks, waiting on a body that never arrives. No authentication, no session, no key exchange.
On its own, that's a connection-exhaustion attack, and those are as old as Slowloris. What makes HollowByte stick is glibc. When the attacker drops the connection, OpenSSL frees the buffer, but glibc holds small and medium chunks for reuse rather than returning them to the kernel.
The attack varies the claimed size on every connection, preventing the allocator from reusing what it freed. The heap fragments, resident set size climbs, and it stays climbed long after the attacker has gone.
Real-World Impact
Okta tested unpatched OpenSSL instances running NGINX. A 1 GB server was OOM-killed with 547 MB of memory frozen in fragments. On a 16 GB server, HollowByte locked up 25% of system memory without ever crossing standard connection limits.
The flaw affects OpenSSL itself and anything that bundles it. That includes web servers like Apache and NGINX, language runtimes like Node.js, Python, Ruby, and PHP, and databases like MySQL and PostgreSQL.
OpenSSL's Decision: Not a Vulnerability
The security team chose to treat HollowByte as a hardening fix rather than a security issue. Even a Low severity issue earns a CVE, a changelog note, and an entry on the vulnerabilities page. HollowByte has none of the three.
The project's line is finer than it looks. Earlier this year, OpenSSL assigned a CVE to a TLS 1.3 certificate-compression bug that required multiple conditions to line up. HollowByte needs none. Another memory-exhaustion issue in the QUIC handler received a CVE and a Moderate rating. HollowByte got nothing.
DTLS Remains Vulnerable
The fix covers TLS only. The DTLS handshake path remains unchanged. The buffer size is still set from the length the peer declares. OpenSSL has not committed to fixing this path.
The Patching Problem
Downstream distributions that backport patches rather than rebasing make detection difficult. A patched package still reports the same version number. Without a CVE, there's no advisory and no OVAL feed to key on.
The only way to confirm the fix is to check whether the distribution rebased on the June 9 release or took the specific patch. The pull requests for the fix cover all affected branches.
The Bottom Line
HollowByte is a memory fragmentation denial-of-service flaw that lets an unauthenticated attacker freeze server memory with an 11-byte payload. The fix exists. There is no CVE. No advisory. No changelog entry.
Upgrade to OpenSSL 4.0.1 or the relevant backported version. If you run a distribution that backports, confirm whether the patch was included. And monitor your TLS servers for unexplained RSS growth, that's your early warning.
FAQ Section
What is HollowByte?
HollowByte is a denial-of-service vulnerability in OpenSSL where an 11-byte TLS payload forces the server to allocate up to 131 KB of memory per connection, causing permanent memory fragmentation.
How does the attack work?
The attacker sends a TLS handshake header claiming a large body size. OpenSSL allocates memory based on that claim before any data arrives. The connection drops, but glibc doesn't release the memory, causing the server's memory to fragment and swell.
Which versions are affected?
All OpenSSL versions before 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21 are affected. DTLS remains vulnerable even in patched versions.
Is there a CVE for this vulnerability?
No. OpenSSL handled HollowByte as a hardening fix without assigning a CVE, advisory, or changelog entry.
What systems are at risk?
Any system using OpenSSL for TLS web servers, databases, language runtimes is affected.
What should I do?
Upgrade to OpenSSL 4.0.1 or the relevant backported version. For distribution users, confirm with your maintainer whether the patch was included. Monitor RSS memory trends for unexplained growth.
