Okta Red Team Publishes "HollowByte" OpenSSL Memory-Freeze Vulnerability Detail After Silent June Fix

A fix that shipped with no CVE, no advisory and no changelog line is now public research — and the tracking gap, not the flaw, is the harder defender problem.

SAN FRANCISCO, CALIF. — Okta's Red Team on July 17, 2026 published technical detail on a denial of service (DoS) vulnerability in OpenSSL that it reported and named "HollowByte" — a memory-exhaustion condition in which eleven bytes of Transport Layer Security (TLS) request data can reportedly cause an unpatched server to set aside as much as 131 KB of memory for a handshake body that never arrives.

The backstory is what makes this a tracking problem rather than a routine patching one. Per The Hacker News, which reported the disclosure, OpenSSL shipped the fix on June 9 in releases 4.0.1, 3.6.3, 3.5.7, 3.4.6 and 3.0.21 with no CVE identifier assigned, no advisory published and no changelog entry pointing at the change. Okta published its writeup a month later. The CyberSignal is not reconstructing the request shape or reproducing the condition; the operationally relevant facts are the affected posture and the absence of a tracking identifier.

What Okta Disclosed

The Okta Red Team's account describes a trust problem in how the TLS handshake was sized. A handshake message declares how long its body will be, and older OpenSSL builds grew the receive buffer to that declared size as soon as the header landed — before any of the body arrived and before the handshake's own checks ran. For an inbound client greeting the ceiling is 131 KB. The connection then waits on a body that never comes: no authentication, no session, no key exchange.

On its own that is a connection-exhaustion pattern defenders have handled since Slowloris. The distinguishing detail is what happens afterward. When the connection drops, OpenSSL frees the buffer, but on glibc systems the allocator retains small and medium chunks for reuse rather than returning them to the kernel. Okta reports that varying the claimed size across connections was enough, in its testing, to stop that memory being reused: the heap fragments and resident set size stays climbed. In its own NGINX tests the firm reported a 1 GB server terminated by the out-of-memory killer with 547 MB frozen in fragments, and a 16 GB server with a quarter of system memory locked up without the connection count crossing the configured ceiling.

The Silent June Fix and Its Disclosure-Policy Implications

The more consequential half of this story is procedural. The pull request carrying the patch records that the OpenSSL security team chose to handle the issue as a "bug or hardening" only fix. OpenSSL's published security policy defines four severity tiers from Critical down to Low, and "bug or hardening" is not one of them. Even a Low-rated issue would normally earn a CVE, a changelog note and an entry on the vulnerabilities page; The Hacker News reported finding none of the three. The same June 9 release reportedly assigned identifiers to two other memory-exhaustion issues and closed 18 CVEs in total.

OpenSSL has not publicly explained the triage, and there is a defensible case for it: a bounded per-connection allocation is not, in isolation, a vulnerability. Okta's counter is that the memory does not come back. The downstream cost is concrete either way. Distributors that backport rather than rebase leave a patched package still reporting the version it was built from, and what normally resolves that ambiguity is an advisory and a machine-readable feed — both keyed to CVE names. There is no name to key on. It is the same tracking failure The CyberSignal documented in the Huawei zero-day behind Luxembourg's 2024 telecom outage, which still carried no CVE ten months later, and in the silently regressed Windows cldflt flaw catalogued as MiniPlasma — and it lands amid a live argument over disclosure norms that The CyberSignal covered when Microsoft condemned uncoordinated zero-day disclosures, except the omission here runs the other direction.

Defender Posture Across OpenSSL-Dependent Server Infrastructure

The remediation instruction is short; the identification work is not. Teams that build OpenSSL themselves should move to the listed June 9 release for their branch and restart whatever loaded the old library — an in-place update does not evict a library already mapped into a running process. Teams consuming vendor packages cannot resolve this from a scanner, because there is nothing to match on; the question to put to a distributor is whether they rebased on the June 9 release or took the patch. That is the gap between patch availability and patch verification in unusually pure form: the patch exists, is shipped, and is invisible to the pipeline that would normally find it.

Scope is the other half. OpenSSL sits underneath reverse proxies, load balancers, mail servers, appliances and container base images, and most inventories record the application rather than the crypto library it links against. The realistic task is to enumerate TLS-terminating services, establish which branch each links against, and confirm the running version rather than the packaged one. Vendor-managed appliances will be slowest to answer — the pattern The CyberSignal has tracked across open-source infrastructure disclosures including the 18-year-old NGINX rewrite-module flaw dubbed Rift, the SquidBleed research disclosure in Squid proxy, the Apache HTTP Server double-free remote code execution flaw, and the HTTP/2 Bomb resource-exhaustion issue.

Detection-Engineering Review

With no identifier to alert on, detection has to work from behavior. The signal Okta describes is resident memory growth on TLS-terminating hosts that persists after connection counts return to normal — a divergence between the two metrics rather than either alone. Teams already graphing both can review historical data for that shape without deploying anything new; teams graphing only connection counts should note the firm's position that standard connection-limiting defenses do not stop this.

Review items: alert on sustained resident-set-size growth for TLS-terminating processes that does not recede when load does; treat out-of-memory kills on TLS front ends as security-relevant rather than capacity noise; and confirm process-restart discipline after library updates, since the glibc behavior Okta reports means the restart is what reclaims the memory.

Open Questions

Several material points are unestablished. Whether OpenSSL has now assigned a CVE to HollowByte is not confirmed, and an identifier appearing later would change the tracking picture materially. The specific patched version for any given deployment is not something this report can establish beyond the release list attributed to The Hacker News; operators should confirm against the branch they run. Whether the flaw has been exploited in the wild is not confirmed — The Hacker News reported finding no public proof-of-concept repository as of July 18 — and whether cloud providers coordinated remediation has not been established.

Two further items sit open technically: whether the fragmentation behavior Okta observed extends to allocators other than glibc, and whether the fix reached OpenSSL's extended-support branches. Reporting also indicates the fix covers the TLS path only, with the DTLS handshake left unchanged and unclassified.

The CyberSignal Analysis

The facts above come from Okta's published research and the reporting. What follows is The CyberSignal's editorial reading of what OpenSSL-dependent organizations should take from this disclosure; none of it introduces new reported facts.

Signal 01 — The Missing Identifier Is the Vulnerability

The per-connection cost here is 131 KB, and reasonable engineers can disagree about whether a bounded allocation deserves a severity rating. What is not arguable is that the absence of a CVE removes this issue from every automated system defenders have built to find such things — scanners, software bills of materials, distributor feeds, patch SLAs. Our reading is that the tracking gap outweighs the technical severity: a Low-rated CVE would have propagated automatically to millions of hosts, while a silent fix reaches only teams who happened to rebase.

Signal 02 — Memory That Does Not Come Back Changes the Threat Model

Connection-exhaustion attacks are a solved category in most mature environments; rate limits, ceilings and upstream scrubbing handle them, and the resource returns when the traffic stops. The characteristic Okta reports — memory stranded in a fragmented heap until process restart — moves the effect out of that category, because the mitigation defenders reach for first operates on a dimension the condition does not depend on. Our assessment is that the durable lesson concerns allocator behavior as an amplifier: a bounded, well-behaved allocation can still produce an unbounded outcome when the layer beneath declines to give the memory back.

Signal 03 — Silent Fixes Push Cost Onto Downstream Maintainers

When an upstream project fixes quietly, the work does not disappear; it transfers. Every distributor, appliance vendor and container-image maintainer now has to determine, by reading commits or asking, whether their build carries a change that has no name. Multiplied across the products embedding OpenSSL, that cost plainly exceeds whatever was saved by not filing an advisory. Our view is that this is the strongest argument for naming even hardening-class fixes in a library this widely embedded: the identifier is not a severity claim, it is a coordination primitive. The watch item is whether OpenSSL revisits the triage, and whether the unclassified DTLS path gets an answer.

Sources