Kiran 
A vulnerability doesn’t need a flashy exploit chain or a catchy CVE number to be dangerous. Sometimes, all it takes is 11 bytes and a library everyone trusts blindly.
That’s the story behind HollowByte, a Denial of Service flaw in OpenSSL discovered by the Okta Red Team, which shows how a tiny, unauthenticated payload can force servers into permanent memory bloat, no handshake required.
Every TLS session starts with a ClientHello message, wrapped in a record that includes a 4-byte header declaring the size of the incoming message body. Older OpenSSL versions took that declaration at face value, allocating a receive buffer before a single byte of actual payload arrived.
OpenSSL “HollowByte” Flaw
HollowByte exploits this blind trust. An attacker sends just 11 bytes: enough to populate the header with an inflated length claim. OpenSSL’s state machine reads that 4-byte header and immediately triggers a pre-allocation through this chain:
Read Header→grow_init_buf()→OPENSSL_clear_realloc()→malloc(attacker_size)
Because no validation occurs at this stage, a single malicious packet can force allocations up to 131 KB. The worker thread then sits idle, waiting on data that will never come.
Holding connections open to starve server threads isn’t new; Slowloris pioneered that tactic over a decade ago. HollowByte adds a nastier twist rooted in how glibc manages memory.
When a connection drops, OpenSSL frees its buffer, but glibc doesn’t hand small-to-medium allocations back to the operating system.
It holds onto them for potential reuse. An attacker who fires waves of connections with randomized sizes claims that prevents the allocator from ever cleanly reusing those freed chunks. The heap fragments, RSS climbs, and the damage outlives the attack itself, only a process restart reclaims the memory.
“What makes HollowByte unsettling isn’t its complexity, it’s the opposite. This is a reminder that DoS research has shifted from brute-force flooding to exploiting the subtle mechanics of memory allocators. Defenders spent years hardening against connection exhaustion; HollowByte shows the next frontier is exhausting the allocator’s patience instead.” Cyber Security News editorial desk
Testing unpatched OpenSSL under NGINX revealed just how disproportionate the impact is. On a 1 GB RAM instance, the server was OOM-killed after fragmenting 547 MB of memory.
On a 16 GB RAM system, attackers locked up 25% of total memory while staying comfortably under standard connection limits, meaning conventional rate-limiting or connection-cap defenses offer no protection here.
Given OpenSSL’s ubiquity, the blast radius is enormous. Web servers like Apache and NGINX, language runtimes including Node.js, Python, Ruby, and PHP, and databases such as MySQL and PostgreSQL all inherit this exposure through their OpenSSL dependencies.
OpenSSL’s maintainers resolved HollowByte by replacing header-trusting allocation with incremental buffer growth, merged via PRs #30792, #30793, and #30794. The fix landed quietly in OpenSSL v4.0.1, with backports to 3.6.3, 3.5.7, 3.4.6, and 3.0.21. Now, buffers grow only as bytes actually arrive on the wire, so an empty claim costs the server nothing.
Notably, OpenSSL classified this as a hardening fix rather than a formal CVE, which means many teams may overlook it in routine patch cycles. Given the scale of downstream dependencies, upgrading your distribution’s OpenSSL packages immediately is a sensible precaution, not an optional one.
About the Author
Potheeswaran 
