HollowByte: 11-byte OpenSSL DoS, no CVE, silent June fix

Eleven bytes of TLS. That’s the payload. In return, Okta’s Red Team says, an unpatched OpenSSL server sets aside up to 131 KB of process memory for a message that never arrives — and on the glibc-linked systems Okta tested, that memory doesn’t come back until the process restarts. Loop that for a few thousand connections and the box tips over. Okta named the bug HollowByte and reported it earlier this year; the public writeup dropped on 2026-07-17, mirrored by BleepingComputer hours later.

What changed

OpenSSL shipped the fix in June with no CVE, no advisory, and no changelog entry pointing at it. If you rebuilt against a June-or-later OpenSSL point release, you already got the patch and never knew that’s what it was. If you’re still on the version you had in May, you’re vulnerable and nothing in your normal patch queue is going to flag it, because nothing in the release metadata says “security fix” — that’s the whole problem the disclosure is now forcing into the open.

The bug itself is a memory-allocation mismatch in TLS record parsing. The parser reserves a buffer sized for a message that the caller has told it to expect, before checking whether the connection actually delivers it. Unauthenticated. No handshake completion required. Standard glibc behavior keeps the reservation live for the life of the process, so a modest number of connections adds up. Okta’s ratio is roughly 12,000-to-1 memory-to-payload, which is a bad ratio.

Nobody is claiming active exploitation. This is a DoS, not an RCE. It has not been added to CISA’s KEV catalog and there is no vendor advisory to attach it to — that’s the point of the disclosure, not an omission on our end.

What to actually do

1. Check the OpenSSL build date on every internet-facing service that terminates TLS: HTTPS, IMAPS, LDAPS, SMTPS, whatever you own. Anything linked against an OpenSSL older than the June 2026 point release for its branch is exposed. Package versions lag; use the build date, not just the marketing version string.
2. Rebuild or repackage against a current OpenSSL. On mainstream distributions this is a routine package update; if it isn’t for you, that’s the honest reason you own that pain, and this is the excuse to fix it.
3. Rate-limit your public TLS listeners at the edge — not as a fix, as a hedge. With HollowByte’s memory-to-payload ratio, even generous per-source connection caps keep a single low-rate attacker from pushing a whole process over.
4. Do not chase this ahead of the CVEs actually being exploited this week. SharePoint CVE-2026-58644 has KEV status and CISA’s Fortinet FortiSandbox additions had a hard patch deadline this weekend. Those are unauth RCEs with active exploitation. HollowByte is neither.

Priority call

Patch it in your next scheduled maintenance window, not tonight. If your instinct every time a named bug shows up is to push OpenSSL updates outside change control, you will burn credibility for the day it actually matters. The DoS surface is real. It is not on fire.

The part that will annoy package maintainers and downstream integrators for longer than the bug itself is the release process. A memory-exhaustion DoS in the library that ships in every mainstream Linux distribution, patched without any of the metadata that would let downstream automation notice, is the exact shape of the problem software-supply-chain auditors already spend their days chasing. Expect the OpenSSL project’s release hygiene to catch louder criticism than the vulnerability. That criticism is fair. It also doesn’t patch anything.

Sourcing

• The Hacker News: OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests — 2026-07-17
• BleepingComputer: HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload — 2026-07-17
• Related: Agent Data Injection: the bug under every AI agent — same shape of problem in a different layer: a class-level defect in a load-bearing component, no clean patch, disclosure forcing the conversation