HollowByte

Eleven bytes of attacker traffic will make an unpatched OpenSSL server reserve up to 131 KB of memory for a handshake body that never arrives. On glibc Linux, that memory does not come back until the process restarts. Okta's Red Team, which found and named HollowByte, published the details Thursday. OpenSSL fixed it a month earlier, on June 9, in releases 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21, with no CVE, no advisory, and no changelog entry. Every release on those branches before the fixed ones is vulnerable, and nothing in a standard patch pipeline will flag it.

How 11 bytes pin 131 KB

Every TLS handshake message starts with a 4-byte header, three bytes of which declare the body length. Pre-fix OpenSSL grew its receive buffer to the declared size the moment the header arrived, before a single body byte landed and before handshake validation ran. For an inbound ClientHello the ceiling is 131 KB. The attacker sends the header, claims a large body, and stops. The worker thread blocks waiting on data that never comes. No authentication, no session, no key exchange required. On its own this is a connection-exhaustion attack in the Slowloris family. The glibc allocator is what turns it into something worse.

glibc makes it permanent

When the attacker drops the connection, OpenSSL frees the buffer, but glibc retains small and medium heap chunks for reuse instead of returning them to the kernel. Okta's attack varies the claimed size on every connection, and in its testing that was enough to defeat reuse. The heap fragments, resident set size climbs, and it stays climbed after the attacker leaves. Against NGINX, Okta OOM-killed a 1 GB server with 547 MB of memory frozen in fragments. On a 16 GB server, the attack locked up 25% of system memory without ever crossing the connection ceiling, which is why Okta says standard connection-limiting defenses won't stop it. The numbers are Okta's own; no public proof-of-concept existed on GitHub as of July 18.

"Bug or hardening," against OpenSSL's own precedent

Matt Caswell, who wrote the patch, said on the pull request that the security team chose to handle this as a "bug or hardening" only fix. That category does not exist in OpenSSL's security policy, which defines four tiers from Critical down to Low. Even a Low rating earns a CVE, a changelog note, and a vulnerabilities-page entry; HollowByte got none. The precedent cuts against the call. In January, OpenSSL assigned CVE-2025-66199, rated Low, to a certificate-compression bug where a peer-supplied length grew a heap buffer before validation, roughly 22 MiB per connection, but only when four separate preconditions lined up. HollowByte needs none of them. The same June 9 release assigned CVE-2026-34183, rated Moderate, to unbounded memory growth in the QUIC PATH_CHALLENGE handler. Both are memory-exhaustion DoS. Both got numbers.

OpenSSL has not said why HollowByte fell below the line. The charitable read is that 131 KB per connection is small and bounded, and every TLS server allocates per-connection memory. Okta's answer is that the memory never comes back.

The downstream gap

If you run upstream builds, the June 9 releases also closed 18 CVEs, including a High-severity use-after-free in PKCS7_verify(), so you likely already patched for other reasons. Distro packages are the problem. Red Hat's documented default is to backport fixes rather than rebase, so a patched package still reports the version it was built from. Normally the advisory and the OVAL feed resolve that ambiguity, and both are keyed to CVE names, which HollowByte lacks. That leaves the package changelog or a direct question to the maintainer: did they rebase on the June 9 release, or take the patch, which is pull request 30792 for master and 4.0, 30793 for 3.6, 3.5, and 3.4, and 30794 for 3.0. If you compile OpenSSL yourself, upgrade to a fixed release and restart every process that loaded the old library.

What to do

Treat this as a patch-now DoS for any internet-facing TLS service on glibc Linux.

• Self-built OpenSSL: upgrade to 4.0.1, 3.6.3, 3.5.7, 3.4.6, or 3.0.21 and restart every dependent service; swapping the library without restarts fixes nothing.
• Distro packages: check the package changelog for pull requests 30792, 30793, or 30794, or ask the maintainer directly; version strings and scanners will not tell you.
• Extended-support 1.1.1 and 1.0.2 users: fix status is unconfirmed; assume vulnerable and ask your support vendor.
• Monitor resident set size on TLS terminators; RSS that climbs and survives connection teardown is the signature.
• Rate-limit at the edge as a stopgap, but do not rely on connection caps; Okta's 16 GB test never hit the connection ceiling.

HollowByte is a modest bug with an outsized process failure attached. The fix exists, is a month old, and is invisible to every automated system built to find it. Until OpenSSL assigns an identifier or explains the triage, finding out whether you are patched is manual work. Do the manual work.