# OpenSSL HollowByte: A Silent Memory Bomb Hiding in Quiet Patches
## The Threat
A critical memory exhaustion flaw in OpenSSL has been silently patched across multiple versions without a CVE identifier, security advisory, or changelog entry. Dubbed HollowByte by Okta's Red Team, the vulnerability allows attackers to freeze up to 25% of a server's RAM using nothing more than carefully crafted 11-byte TLS handshake requests—and the memory never comes back until the process restarts.
The issue affects OpenSSL versions:
The patch was shipped with minimal fanfare—buried as a "bug or hardening" fix rather than classified as a vulnerability. In Okta's testing, a 1 GB NGINX server was killed by out-of-memory conditions with 547 MB locked in memory fragments, while a 16 GB server lost a quarter of its usable memory to fragmentation.
## Background and Context
OpenSSL's classification system defines four severity tiers: Critical, High, Medium, and Low. Anything below Critical receives a CVE identifier, a public advisory, and a changelog entry. HollowByte received none of these.
The project's reasoning appears straightforward on its surface: allocating 131 KB per TLS connection is routine, bounded allocations are standard practice, and 131 KB is not inherently catastrophic. OpenSSL's security policy does not list "undisclosed memory fragmentation" as a vulnerability class.
However, the decision has drawn sharp criticism. In January 2026, OpenSSL assigned CVE-2025-66199 (rated Low) to a TLS 1.3 certificate-compression bug that could grow heap buffers by around 22 MiB per connection—but that flaw required four conditions to align: certificate compression must be compiled in, a compression algorithm must be available, the extension must be negotiated, and on servers, client certificates must be requested. HollowByte needs none of these prerequisites.
The vulnerability was discovered and reported by Okta's Red Team, who published technical details on July 17, 2026—more than a month after the patches were silently released. The delayed disclosure left every unpatched server exposed without any way to identify the risk through normal vulnerability scanning processes.
## Technical Details
### How the Attack Works
Every TLS handshake message begins with a 4-byte header. The first byte identifies the message type, and the next three bytes declare the length of the message body. OpenSSL's vulnerability lies in its trust of that length declaration:
1. Attacker sends crafted header: A malicious client transmits a TLS handshake message header claiming a body length of up to 131 KB (the ceiling for ClientHello messages)
2. Memory allocated immediately: OpenSSL allocates the full 131 KB buffer the moment the header arrives—before any body bytes arrive, and crucially, before the handshake's own validation checks run
3. Body never arrives: The attacker drops the connection, leaving the buffer allocated but empty
4. Memory fragments and persists: Here's where it gets dangerous
### The Fragmentation Problem
On systems using glibc (the GNU C Standard Library), the memory behavior diverges sharply from what administrators might expect:
### Real-World Impact
In Okta's testing environment:
| Scenario | Result |
|----------|--------|
| 1 GB NGINX server | Out-of-memory kill after 547 MB fragmented |
| 16 GB NGINX server | 25% of memory (4 GB+) locked in fragments |
| Connection ceiling | Never exceeded; standard connection limits useless |
| Memory recovery | None until process restart |
The attack does not require authentication, a valid session, key exchange, or even a complete handshake. An unauthenticated attacker from any network can trigger the condition.
## Implications
### Why Standard Defenses Fail
Connection-limiting rules—a standard mitigation for TLS-based denial-of-service attacks—provide no protection against HollowByte. Traditional connection exhaustion attacks fill up the connection table; administrators can cap connections and reject new ones. With HollowByte, the attacker doesn't need many connections; memory fragments with each one, and the damage accumulates across legitimate and malicious traffic alike.
### Who Is Exposed
Any organization running an unpatched OpenSSL version is at risk:
The lack of a CVE identifier and public advisory means many organizations have no way to identify whether they are affected. Vulnerability scanners have no identifier to match. Security information and event management (SIEM) platforms have no alert to generate. Patch management systems have no flag to highlight the release.
### Supply Chain Risk
The silent classification raises a troubling precedent: if a memory exhaustion flaw merits no disclosure, what other vulnerabilities might exist in patches without formal CVE assignment? Organizations cannot assume silence equals safety.
## Recommendations
### Immediate Actions
1. Audit your OpenSSL versions across all systems (servers, appliances, development machines):
```
openssl version -a
```
2. Prioritize patching the following versions to their fixed counterparts:
- Any 4.0.x → upgrade to 4.0.1 or later
- Any 3.6.x → upgrade to 3.6.3 or later
- Any 3.5.x → upgrade to 3.5.7 or later
- Any 3.4.x → upgrade to 3.4.6 or later
- Any 3.0.x → upgrade to 3.0.21 or later
3. Confirm patch application:
```
openssl version
```
Verify the release date is June 9, 2026 or later.
4. Contact OpenSSL if you rely on extended-support branches 1.1.1 or 1.0.2 to confirm whether patches are available.
### Longer-Term Hardening
---
## HackWire Analysis
The HollowByte incident exposes a fundamental tension in open-source security disclosure: when does a patch stop being a routine maintenance update and become a vulnerability? OpenSSL's decision to classify this as a bug-fix rather than a security issue reflects a narrow technical view—131 KB per connection *is* bounded, and memory *does* return eventually. But that framing ignores the real-world behavior of modern memory allocators on production systems.
What makes HollowByte remarkable is not the bug itself—memory exhaustion flaws in TLS stacks are well-known—but the *stealth*. For over a month, all five affected release lines were patched without any of the standard machinery that alerts defenders: no CVE, no advisory, no scanner signatures. An attacker with early knowledge of the fix could infer the vulnerability from patch analysis and exploit unpatched systems while defenders remained unaware a risk even existed.
This also reveals a deeper pattern: the OpenSSL project's classification bar has grown inconsistent. A certificate-compression flaw affecting 22 MB per connection earned a CVE and public advisory despite requiring four separate conditions to trigger. HollowByte, needing none, was buried. Neither assessment is objectively wrong—but inconsistency erodes trust. Organizations now have legitimate reason to ask: what else have we missed because it was classified down?
The fragmentation angle is also underappreciated in early coverage. glibc's behavior—holding freed memory in a free list rather than returning it immediately—is not exotic; it's the default allocator on Linux systems running the vast majority of production TLS infrastructure. Okta's 25% memory loss on a 16 GB server is not a lab anomaly; it's realistic to how actual deployments will behave. That changes the risk calculus significantly.
Defenders should treat this incident as a signal that silent patches warrant the same attention as loud CVEs. When a stable release lands without fanfare and no changelog, dig into the commits. Consistency in disclosure may matter less than consistency in *verification*. — HackWire Editorial
---
## Related Coverage