Eleven bytes will make an unpatched OpenSSL server set aside up to 131 KB of memory for a message that never arrives.
What HollowByte does to a TLS handshake
The bug, named HollowByte by Okta's Red Team, stems from OpenSSL trusting a peer-supplied length in a TLS handshake header. Every TLS message has a four-byte header; three of those bytes declare the body length. Older OpenSSL code expanded the receive buffer to the declared size the moment the header landed—before any of the body arrived and before the handshake's own checks ran. For a ClientHello the ceiling is 131 KB. The result is a worker thread blocked waiting on a body that never comes: no authentication, no session, no key exchange.
Okta's Red Team testing: memory frozen, not just connections
On the glibc systems Okta tested, freed buffers did not return memory to the kernel. OpenSSL frees the buffer when the attacker drops the connection, but glibc keeps small and medium chunks for reuse. Okta's tests varied the claimed size on every connection, which prevented the allocator from reusing freed chunks. The heap fragmented; resident set size climbed and stayed climbed after the attacker left.
In NGINX testing reported by Okta, a 1 GB server was OOM‑killed with 547 MB of memory frozen in fragments. On a 16 GB server, HollowByte locked up 25% of system memory without ever crossing OpenSSL's connection ceiling — a result the Red Team summarized with a warning that "standard connection-limiting defenses won't stop it". The Hacker News did not find a public proof‑of‑concept repository on GitHub as of July 18, and Okta published its details on Thursday.
OpenSSL's patch, release dates, and the triage decision
OpenSSL shipped a fix on June 9 in releases 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. The pull request author, Matt Caswell, described the team's choice to "handle this as a 'bug or hardening' only fix." OpenSSL's security policy defines four severity tiers—Critical down to Low—and "bug or hardening" is not one of them. Unlike even Low-rated issues, HollowByte received no CVE, no advisory, and no changelog entry pointing to the change; the Hacker News found no mention of the fix in the 4.0.1 changelog or in the project's vulnerabilities page.
The project's release on June 9 did assign CVE‑2026‑34183 (Moderate) to an unbounded memory growth issue in QUIC PATH_CHALLENGE and CVE‑2025‑66199 (Low) to a TLS 1.3 certificate‑compression heap growth bug, and it closed 18 CVEs including a High‑severity use‑after‑free in PKCS7_verify(). The HollowByte patch is present in pull request 30792 for master and 4.0, 30793 for 3.6/3.5/3.4, and 30794 for 3.0.
Downstream packaging, backports, and remediation steps
Downstream distributions complicate discovery. Red Hat's documented default is to backport fixes rather than change the reported version string; a patched package can still report the version it was built from. Normally, advisories and OVAL feeds keyed to CVE identifiers let administrators detect backports; with no CVE, those automated signals are absent.
If you build OpenSSL yourself, the source advises upgrading to one of the listed June 9 releases and restarting "whatever loaded the old one." If you rely on a vendor package, the practical step is to ask the package maintainer whether they rebased on the June 9 release or applied the pull request (30792/30793/30794).
How technologists, maintainers, and adversaries are likely to respond
- Technologists and security teams: Expect to check deployed OpenSSL builds for the June 9 fixes and to restart services that load OpenSSL. Because there is no CVE or advisory to search for, teams will need to verify upstream version or confirm backport status with their vendor.
- Downstream maintainers and packagers: They will have to answer customers' questions about whether the backport was applied or if the package was rebased to the June 9 releases; the relevant pull requests are 30792, 30793, and 30794.
- Adversaries and red teams: The bug is a connection‑exhaustion vector that becomes persistent on glibc allocators; Okta's testing showed fragmentation that survives connection teardown. Whether other allocators reproduce the same fragmentation effect is a question Okta was asked but had not yet answered publicly.
One fix exists and is published; one classification decision remains the story's sting. OpenSSL fixed the TLS path in the June 9 releases but chose not to treat HollowByte as a vulnerability worthy of a CVE, while deliberately leaving DTLS alone because a proper DTLS fix would have been more invasive—OpenSSL's DTLS handshake file was found byte‑identical between 3.6.2 and 3.6.3, and in 4.0.1 that DTLS path still sizes its buffer from the peer‑declared length. Administrators must therefore do two things: ensure their builds contain the June 9 fixes and ask their packagers whether those fixes were applied or backported, because automated CVE‑based signals will not find this change for them.
