Researchers at Okta's Red Team have disclosed HollowByte, a denial-of-service weakness in how OpenSSL — the encryption library underpinning most of the internet's secure connections — handles the start of a TLS handshake. The flaw needs no username, password, or user interaction. It needs eleven bytes.
Every TLS message opens with a short header stating how much data is about to follow. Vulnerable OpenSSL versions take that number on faith and immediately reserve memory for the full amount — up to 131 KB per connection — before a single byte of the actual payload arrives. An attacker sends the 11-byte header, claims a large payload is coming, then never sends it and drops the connection. Repeat that thousands of times with a different claimed size each time, and something worse than a simple memory leak happens: on Linux systems using the standard glibc allocator, that reserved memory fragments into pieces too small to reuse, so it's never reclaimed even after connections close. In Okta's testing, a 1 GB NGINX server crashed with roughly 547 MB trapped in fragments; 16 GB systems lost about a quarter of their memory without ever tripping a connection-rate limit — the usual first line of defence against this kind of attack.
OpenSSL shipped a fix on 9 June (versions 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21) that now grows the receive buffer only as real data arrives, instead of trusting the header's claim upfront. One detail is worth flagging: OpenSSL classified this as a "hardening" improvement rather than a formal vulnerability, so no CVE was assigned — a quiet decision with a real consequence, since scanners and patch-tracking tools that key off CVE feeds won't flag an unpatched server as at risk.
What this means for your business
- Check your OpenSSL version directly — don't rely on your scanner. Run
openssl versionon servers that terminate TLS and confirm you're on 4.0.1, 3.6.3, 3.5.7, 3.4.6, 3.0.21, or newer. Because there's no CVE, automated tools tied to CVE databases may report you as clean when you're not. - This is bigger than "your web server." OpenSSL sits underneath NGINX, Apache, Node.js, Python, Ruby, PHP, and database servers like MySQL and PostgreSQL wherever they handle TLS directly. Any Linux box terminating encrypted connections is worth checking, not just the obvious front-end server.
- Watch memory trend, not just connection counts. Because this attack fragments memory rather than opening excess connections, standard rate-limiting and connection caps won't catch it. Steadily climbing memory usage under normal-looking traffic is the signature to watch for.
- If you're behind a managed host or CDN, ask rather than assume. Confirm with your hosting provider that their edge and origin servers are patched — this is exactly the kind of infrastructure-layer fix that's easy for a vendor to quietly miss without a CVE forcing the issue.
Six weeks between a quiet patch and the first headline is a familiar pattern by now — the fix works whether or not anyone noticed the release notes, but only once it's actually installed. If nobody on your team can confirm which OpenSSL version your servers are running today, that's this week's five-minute task.