SURIQ
The most useful detail about HollowByte is not that eleven bytes can wedge an OpenSSL server. It is that OpenSSL fixed the flaw on June 9, 2026 without assigning a CVE, without a security advisory, and, by its own classification, below the Low severity tier. For most shops, the CVE is the trigger. It is what the vulnerability scanner keys on, what the patch SLA counts down from, what shows up in the weekly report. Take that signal away and a trivially exploitable denial-of-service condition sits in one of the most widely deployed libraries on your fleet with nothing pointing at it.
The flaw was found and named by Okta's Red Team, who published the details in mid-July, weeks after the quiet fix. That gap between the patch and the public write-up is the window this post is about.
What the eleven bytes actually do
A TLS handshake message begins with a small header whose length field, three bytes of it, states how big the body still to come will be. The vulnerable builds took that figure at face value and expanded the receive buffer to match as soon as the header arrived, without waiting for any of the body to show up. For a ClientHello the reserved block runs to roughly 131 KB. An attacker sends the header, declares a large body, then sends nothing more. The memory is committed, and the half-open connection just sits there.
None of this needs authentication, a finished handshake, or a key exchange. It lands at the opening moment of the connection, so every service that terminates TLS is in range. Dropping the connection does hand the buffer back to OpenSSL, which releases it correctly. What happens one layer beneath that release is where it goes wrong.
Why the memory does not come back
On the glibc-based systems Okta used, as reported by BleepingComputer, a released buffer is not returned straight to the kernel. The allocator retains blocks of that size on the assumption it will want them again soon. Feed it a stream of connections with different declared sizes and those retained blocks never line up for reuse, so the heap splinters and the committed memory stays committed. Only restarting the process gives it back.
Okta's figures show the effect. Against NGINX, a host with 1 GB of memory was driven into an out-of-memory kill, with 547 MB stuck in fragments that never freed. A 16 GB host lost about a quarter of its memory. The traffic needed to get there stayed under the volume most teams would alarm on, and that is the part that matters more than the raw megabytes.
| OpenSSL branch | First fixed build | Patched |
|---|---|---|
| 4.0 | 4.0.1 | Yes |
| 3.6 | 3.6.3 | Yes |
| 3.5 | 3.5.7 | Yes |
| 3.4 | 3.4.6 | Yes |
| 3.0 | 3.0.21 | Yes |
| End-of-life branches | no fix planned | No |
The missing CVE is the real exposure
Patching this is easy. The five supported branches all shipped a fixed build on the same day: 3.0.21, 3.4.6, 3.5.7, 3.6.3, and 4.0.1. The hard part is knowing you need to. A CVE is the thread that ties a disclosure to your systems: your scanner matches it against installed versions, your ticketing system opens work against it, your compliance report lists it as open or closed. HollowByte has none of that. If your patching is driven by CVE feeds, this fix is invisible to it, and you will pick it up only when the base image or distribution package happens to roll forward for some other reason.
That makes version inventory, not CVE matching, the only reliable way to find your exposure here. You need to know which OpenSSL build each host actually runs, and whether it predates June 9. This is the same distribution-gap failure that turned a small Node.js denial-of-service fix into a long-tail problem: the patch existed almost immediately, but reaching every place the code was embedded took far longer. OpenSSL is embedded in more of your stack than almost anything else: your web servers such as Apache and NGINX, language runtimes for Python, Ruby, PHP, and Node.js, and databases like PostgreSQL and MySQL all link against it. One host can carry several independent copies at different versions.
Patching stops new damage. It does not undo old damage.
There is a second trap in the remediation, and it comes straight from the memory behavior above. Updating the OpenSSL build stops a process from over-allocating on future connections. It does nothing for a process that is already bloated. Because glibc holds the stranded arena for the life of the process, a worker that got hit before you patched keeps that memory locked until it restarts. So the real remediation is two steps, not one: update the library, then reload or restart the processes that terminate TLS. Patch without the reload and a server that was already attacked stays degraded.
Two more scope notes worth pinning down. The affected process is whatever holds the listening socket, so on a typical web host that is NGINX, HAProxy, or your application runtime, and the fix and the reload have to reach each of them independently. And DTLS, the datagram flavor of TLS used by some VPNs, WebRTC, and IoT services, was still unpatched when the details went public. If you run a DTLS endpoint, patching your web tier does not cover it.
Detect it by memory shape, not by traffic
The instinct with a flood-style attack is to reach for rate limiting, but standard connection-limiting defenses will not stop this one. The requests are cheap and few, and the bandwidth stays under the threshold that would trip a volumetric alert. Watching request rates is watching the wrong axis.
The signal that does show is memory. A TLS-terminating worker whose resident memory climbs and stays climbed, while its connection count and request volume look normal, is the fingerprint of this class of attack. That is a host-metric correlation: process memory growth decoupled from load, ideally tied to the specific worker holding the TLS socket. It is exactly the kind of behavioral signal a managed detection setup is meant to surface when a signature-based control has nothing to match, because here there is no CVE and no payload signature to match against. As of mid-July there was no public proof-of-concept for HollowByte, which buys a little time, but a memory-exhaustion primitive this simple does not stay theoretical for long.
Inventory your OpenSSL builds, then reload the terminators
Start by finding every OpenSSL your hosts actually run, not just the one your base image advertises. Any build on the 3.0, 3.4, 3.5, 3.6, or 4.0 branches dated before June 9, 2026 is exposed, and end-of-life branches are not getting a fix at all, so anything past its support window needs a migration plan rather than a patch. Update to the fixed builds, then reload or restart every process that terminates TLS so no already-bloated worker keeps its stranded memory. Check separately for DTLS endpoints, which were not covered when this went public. Track the exposure by installed version through your own vulnerability detection, because the usual CVE feed will not raise it for you. This belongs in the same bucket as the recent NetScaler memory-leak fixes: a resource-exhaustion bug where the download is only half the job and the reload or config change is the part people skip.