astropod sign in

Eleven Bytes, No CVE: The OpenSSL HollowByte Flaw That Scanners Miss

2026-07-21 01:02:58 · Chris vulnerability-intelligencesoftware-supply-chain-securityopenssldenial-of-servicetlssbom

Published on gastropod.io - 07-20-2026

Eleven Bytes, No CVE: The OpenSSL HollowByte Flaw That Scanners Miss

Tags: vulnerability-intelligence, software-supply-chain-security, openssl, denial-of-service, tls, sbom, dependency-management

Most of the memorable vulnerabilities this year have been loud. HollowByte is the opposite. It is eleven bytes, and if your vulnerability pipeline is doing its normal job, it will sail straight past you.

Okta's Red Team disclosed the bug last Thursday (7-16-2026). The mechanics are almost insultingly simple. Every TLS handshake message starts with a four-byte header, three bytes of which announce how long the body will be. Older OpenSSL versions used/trusted that number. They grew the receive buffer to the declared size the instant the header arrived, before a single byte of the body showed up and before the handshake's own sanity checks ran. Send an eleven-byte packet that claims a much larger body is coming, and the server sets aside up to 131 KB for a message that never arrives, then parks a worker thread waiting for data you will never send. No authentication, no completed session, no key exchange.

131 KB does not sound frightening on its own, however this is where OpenSSL had an issue. When the connection eventually drops, OpenSSL frees the buffer, but glibc holds onto small and medium chunks for reuse instead of handing them back to the kernel. Vary the claimed size on every connection and the allocator cannot reuse what it freed, the heap fragments, and resident memory climbs and stays frozen in place long after the attacker has gone. In Okta's own NGINX testing, a 1 GB server was OOM-killed with 547 MB frozen in fragments, and a 16 GB server lost a quarter of its memory without ever crossing the connection limits that would normally trip an alert. There is no public exploit code yet, which buys everyone a little time.

Here is the part that should get a your appsec team's attention. OpenSSL shipped the fix back on June 9, in releases 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. It did so with no CVE, no security advisory, and no changelog entry pointing at it. The project chose to treat it as a "bug or hardening" fix, a category that sits below even the Low tier in its own severity policy. The same June release handed out CVE numbers to two other memory-exhaustion bugs and closed eighteen more, so this was a deliberate call rather than an oversight. The result is a real, remotely triggerable denial-of-service condition with nothing for a scanner to match on and no advisory for anyone to read.

That is the whole problem in one sentence. Vulnerability management, as most shops run it, is a name-matching exercise: a feed publishes a CVE, your scanner checks your inventory against the name, you patch what lights up. Take away the name and the machinery has nothing to grip. It gets worse downstream. Red Hat and others backport fixes rather than bumping the version string, so a patched package can still report the version it was built from, and the thing that normally untangles that is the advisory and its CVE-keyed OVAL feed. No CVE, no key. To actually know whether a given build is safe you have to read the package changelog or ask the maintainer whether they rebased on the June 9 release or pulled the specific patch. And none of that touches the copies of OpenSSL statically bundled inside language runtimes and container images, which an operating-system patch will never reach.

Some source reading

When there is no CVE to look up

Advisory correlation, the feature most tools reach for first, is exactly the thing HollowByte defeats. If there is no CVE, an OSV lookup has nothing to return, and that is as true for us as it is for anyone else. So the honest question is not which tool has the advisory. It is what you fall back on when there is no advisory at all.

The answer is inventory you can actually query, because you do not need a CVE to know the fix line. HollowByte is not really an advisory problem, it is a "where is this version, and who is pulling it" problem. The patched releases are known and dated: 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21, all shipped June 9. Once you have that boundary, sorting your estate stops being an advisory lookup and becomes a question of which side of the line each of your OpenSSL artifacts falls on. That is how we do it at gastropod.io. Every artifact that flows through picks up a content-addressed identity: the exact package, version, and sha256 digest, pinned to the artifact itself rather than taken on faith from a self-reported string. A CycloneDX SBOM gets reconstructed on demand, and the where-seen history and blast-radius graph tell you every image that carries a given OpenSSL and every service that pulled it. So the question the June 9 fix actually forces, which of my builds are behind the fix line and what pulls them, becomes a boundary check against your own registry rather than a fleet-wide dig through changelogs. And once you have decided a version behind that line is not welcome, an intake rule keeps the next copy from coming through the door, CVE or not.

None of this makes the DoS disappear, but the caveat is smaller than I first made it sound, and you have put your finger on why. The version string is not what gets trusted here: every artifact is pinned to its sha256. A distro that backports the patch normally bumps its release field anyway, and even if someone rebuilt without touching a single version character, the bytes changed, so the digest changed. A backported 3.0.7 is a different artifact from stock vulnerable 3.0.7, and different again from upstream 3.0.21. A rebuild that keeps the old number does not pass for the original, it surfaces as its own distinct thing. The one job a hash will not do on its own is tell you which of those distinct builds carries the fix. That is a matching problem rather than a mind-reading one: line the digest up against the distro's known-good build, and only if no such reference exists are you back to a changelog or a one-time look at the bytes. Content-addressing is what makes that comparison possible at all, where a bare version number cannot separate the patched build from the vulnerable one. If HollowByte has you wondering what your own images are actually built on, that seems like you might want to point a client at Gastropod and look.

Because the uncomfortable lesson here is not that OpenSSL made the wrong call on a severity rating. It is that a fix can ship correctly, on time, and completely silently, and the only teams who notice are the ones who already know what is in their software.

← news