An 11-byte TLS payload can lock up to 131 KB of server memory indefinitely on unpatched OpenSSL instances, and most operators had no way of knowing a fix had shipped.
Summary
- Okta’s Red Team discovered and named HollowByte, a denial-of-service vulnerability in OpenSSL that allows an attacker to exhaust server memory using a minimal 11-byte TLS request.
- Each malformed request causes the server to reserve up to 131 KB of memory for a message that never arrives; on glibc-based systems, that memory is not released until the process restarts.
- OpenSSL shipped a fix in June, but did so without issuing a CVE, a security advisory, or any changelog entry that would alert operators to the nature of the change.
- Because there was no public disclosure tied to the patch, organisations relying on vulnerability feeds or advisories to trigger patching may still be running vulnerable versions.
- Okta’s Red Team published details of the flaw, effectively creating the first public signal that prompted wider attention.
What the vulnerability does
HollowByte exploits the way unpatched OpenSSL handles certain TLS requests. When a server receives an 11-byte payload crafted to trigger the flaw, it allocates up to 131 KB of memory in anticipation of a message body that never follows. The allocation sits idle and, on systems running glibc — the standard C library on the vast majority of Linux distributions — that memory is not reclaimed until the affected process is restarted. An attacker who can send a sustained volume of these requests can progressively exhaust the server’s available memory, degrading or halting service.
A patch with no paper trail
OpenSSL addressed the issue in June, but the release was handled without the usual disclosure mechanisms that the security community depends on. No CVE identifier was assigned, no security advisory was published, and the relevant changelog entry did not flag the change as a security fix. For organisations that manage patching through vulnerability management platforms, advisory subscriptions, or CVE-based tooling, there was effectively no signal that anything requiring urgent attention had shipped. The patch existed; the context around it did not.
Okta’s role in bringing it to light
It was Okta’s Red Team that identified the vulnerability, reported it to OpenSSL, and subsequently published their findings — including the name HollowByte. Their publication is the primary reason the broader community is now aware that the June update carried a material security fix. Without that research disclosure, the window between patch availability and operator awareness could have extended indefinitely for teams not conducting their own code-level review of OpenSSL releases.
Why silent patching creates its own risk
The mechanics of HollowByte are concerning, but the disclosure approach raises a separate and arguably more systemic issue. When a maintainer of a foundational cryptographic library ships a security-relevant fix without labelling it as such, it undermines the patch management workflows that most enterprises have built in good faith. Security teams prioritise updates based on severity ratings and advisory feeds. A fix that arrives without that context will, in many environments, simply wait in a queue behind work that carries a visible risk label. The result is a gap between when a patch is available and when it is actually applied — and that gap is entirely attributable to the lack of transparency, not to operator negligence.
Scope and affected systems
The memory retention behaviour Okta confirmed was specific to glibc-based systems, which encompass the overwhelming majority of Linux server deployments. The sources do not specify which OpenSSL versions are affected beyond the implication that the June release contains the fix, and they do not detail whether non-glibc environments such as musl-based distributions or non-Linux platforms exhibit different behaviour. Organisations should verify their OpenSSL version against the June release and test accordingly.
Why it matters
OpenSSL underpins TLS across an enormous proportion of internet-facing infrastructure. A low-cost denial-of-service primitive that requires only 11 bytes per request and produces memory loss that persists until a process restart is exactly the kind of primitive threat actors incorporate into sustained disruption campaigns. More broadly, this incident illustrates a governance gap: if a library of this importance can ship a security fix without any of the disclosure artefacts that enterprise patch management depends on, CISOs need to ask whether their current processes would have caught it. Relying solely on CVE feeds and advisory subscriptions is demonstrably insufficient when upstream maintainers do not consistently follow coordinated disclosure conventions.
What to do now
- Audit all systems running OpenSSL and confirm whether the June patch has been applied; do not assume that routine update cycles have captured it given the absence of advisory signalling.
- Check whether your vulnerability management tooling flagged the June OpenSSL release; if it did not, treat this as a process gap requiring attention.
- For internet-facing services using OpenSSL, assess exposure to high-volume TLS connection attempts and consider whether existing rate-limiting or connection throttling controls would constrain the impact of a HollowByte-style attack.
- Review your dependency on CVE-based alerting as a sole patching trigger and consider supplementing it with direct monitoring of upstream release notes for critical libraries such as OpenSSL.
- If your organisation uses glibc-based Linux systems — which most enterprise Linux environments do — treat this as a confirmed affected platform and prioritise patching accordingly.
