# Eleven Bytes and a Waiting Thread: What OpenSSL's HollowByte Says About Silent Patching
The payload that could drop your server is 11 bytes. That's shorter than "Hello world." And until last week, most of the people running OpenSSL-backed infrastructure had no idea it existed — because OpenSSL didn't tell them.
Okta's red team published research this weekend on HollowByte, a denial-of-service vulnerability they discovered in OpenSSL's TLS stack. The short version: an attacker can send a crafted 11-byte message that causes OpenSSL to pre-allocate up to 131 KB of memory, then walk away. The server's worker thread sits there waiting for data that will never come. Do that enough times with randomized claimed sizes, and you fragment the allocator so badly that even after every connection drops, the memory doesn't come back. The only fix is killing the process.
OpenSSL quietly shipped the patch in version 4.0.1. No CVE. No advisory. No "hey, this is a security fix" in the changelog.
That choice deserves more scrutiny than it's getting.
## How the Bug Works
To understand HollowByte, you need to understand something about how TLS handshakes are structured. Every handshake message carries a 4-byte header declaring the size of the body that follows. Historically, OpenSSL used that declared size to pre-allocate a receive buffer — the idea being that grabbing memory upfront is more efficient than growing it incrementally.
The flaw is that this pre-allocation happened *before any data arrived*. An attacker could send a message declaring a 131 KB body, trigger the allocation, then simply stop transmitting. The worker thread blocks indefinitely on a read that will never complete.
That alone would be manageable — modern systems can handle some blocked threads. But Okta's researchers found the interaction with glibc's memory allocator made it catastrophic at scale.
When OpenSSL eventually frees the stalled buffer, glibc doesn't return that memory to the operating system. It holds onto small-to-medium allocations for potential reuse — a performance optimization that becomes a liability here. By sending waves of connections with *randomized* claimed sizes, an attacker prevents the allocator from ever reusing those freed chunks efficiently. Memory fragments pile up. The heap bloats. The server becomes sluggish, then unresponsive.
In Okta's testing on a 1 GB system, 547 MB was fragmented and frozen before the machine went dark. On a 16 GB system, the attack pinned 25% of total memory while staying well under connection-rate thresholds — meaning the rate-limiting rules most operators have configured would not have triggered a single alert.
## The Blast Radius Is the Entire Stack
HollowByte isn't scoped to a niche product. OpenSSL is the cryptographic substrate for most of the internet's TLS infrastructure. Apache, NGINX, Node.js, Python, Ruby, PHP, MySQL, PostgreSQL — the affected list reads like a taxonomy of web infrastructure. If it speaks TLS and it links against OpenSSL, it was potentially vulnerable.
The patched versions are OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. Organizations running anything older are still exposed. And because the fix was silent — no CVE, no security advisory — many teams simply have no reason to prioritize the upgrade. This is the operational problem with silent patching at scale.
OpenSSL's fix was straightforward and correct: the library now grows the buffer incrementally as bytes actually arrive rather than trusting the declared size upfront. This is how it should have worked from the start. But the patch's quiet arrival means defenders aren't connecting urgency to the version numbers they see in their asset inventory.
## Silence Isn't Stealth
There's a case for silent security patches — typically around zero-days being actively exploited, where you want attackers to lose capability before they know it's coming. But HollowByte doesn't fit that profile. This was a researcher-discovered bug reported responsibly through Okta. The coordinated disclosure process existed precisely to allow time-boxed secrecy followed by public transparency.
What OpenSSL's approach produced instead is a situation where:
Silent patching optimizes for one thing: making the vendor look like the vulnerability was minor. That's a reputational calculation, not a security one. The security community has largely moved past "security through obscurity" as a philosophy, but it keeps creeping back in packaging decisions like this.
## What Defenders Should Actually Do
Standard rate-limiting won't protect you here — the attack specifically stays under connection ceilings. The useful controls are:
Upgrade immediately. The fix is available and the blast radius is enormous. OpenSSL 3.0.21, 3.4.6, 3.5.7, 3.6.3, or 4.0.1 all contain the patch. Check your package manager, your base images, and anything that statically links against the library.
Know your OpenSSL version in production. Many teams don't. Run openssl version on your servers. Check your container images. If you're on a platform like AWS or GCP and relying on managed TLS termination, verify which library version your provider is running.
Memory monitoring needs context. A slow memory climb under moderate connection load is the HollowByte fingerprint. Alerts tuned only to CPU spikes or connection counts won't catch it. Add heap size trending to your server monitoring.
Restart policies matter. Until patched, graceful restarts on a schedule can clear fragmented allocators. Not a fix, but it raises the cost of the attack for the adversary.
## HackWire Analysis
HollowByte is a clean example of a vulnerability class that security teams tend to underweight: pre-authentication resource exhaustion that operates below traditional detection thresholds. It doesn't need credentials. It doesn't need a flood. It doesn't even need a particularly fast network connection — 11 bytes per connection, randomized sizes, patient execution.
The glibc interaction is what elevates this from "annoying DoS" to "architecture problem." The vulnerability crosses two library boundaries: OpenSSL's trust of declared header sizes, and glibc's retention of freed allocations. Neither behavior is wrong in isolation. Together, they create a condition that persists after the attacker disconnects. That's the insidious part — you can kick all the active attackers off and still have a broken server.
What the coverage is missing is the broader argument this makes about OpenSSL governance. This is not the first time OpenSSL has shipped security-relevant fixes without advisories. The project's disclosure practices have been inconsistent for years, and HollowByte is another data point in that pattern. For organizations managing compliance posture or running vendor software that bundles OpenSSL, the absence of a CVE number isn't a green light — it's a gap in visibility.
The infrastructure operators most at risk aren't the ones running bare-metal web servers where someone will notice the OpenSSL changelog. They're the teams running dozens of services built on frameworks that bundle OpenSSL internally, where no one checks the transitive dependency version unless a CVE forces the issue.
That's the gap HollowByte exploits. Not in the code — in the process.
— HackWire Editorial
## Related Coverage