HollowByte is a noteworthy OpenSSL flaw because it does not require complex exploit code, authentication, or even a CVE for vulnerability scanners to identify easily. According to The Hacker News, the Okta Red Team said that a very small TLS packet header can cause an unpatched OpenSSL server to allocate memory and then wait for body data that never arrives.
How HollowByte works
During the TLS handshake, messages include a header that declares the body length. In affected OpenSSL versions, the library may trust the length declared by the peer and expand the receive buffer before the body has actually been sent in full.
The danger is that an attacker does not need to complete the TLS session. By sending just enough of the header for the server to prepare memory, then holding or closing the connection, the TLS-serving process may already have gone through an unnecessary memory allocation cycle. When this is repeated across many connections, the process resident memory grows and the service may be terminated by the operating system because RAM is exhausted.
Why 11 bytes matter
The figure of 11 bytes sounds almost too small to matter, but denial-of-service attacks are not always about the volume of data sent in. The risk appears when a small input triggers a resource-expensive reaction on the server side. This is a familiar pattern in many connection-exhaustion and memory-exhaustion attacks.
The Hacker News, citing Okta analysis, noted that on some systems using glibc, memory freed by OpenSSL is not necessarily returned immediately to the operating system. When allocation sizes change repeatedly, the heap can become fragmented, causing the process RSS to grow and remain high even after the malicious connection has disappeared.
The hard part: no CVE to track
OpenSSL included the fix in releases dated June 9, including OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. However, the issue was handled as a bug fix or hardening change, with no CVE, no dedicated advisory, and no prominent changelog entry in the way operations teams usually expect.
That makes life harder for administrators. Many vulnerability management workflows depend on CVEs, OVAL feeds, or operating-system vendor alerts. When there is no clear identifier, determining whether a server has received the HollowByte fix requires deeper checks of package versions, downstream changelogs, or maintainer confirmation.
Which systems need attention
Services that use OpenSSL to handle server-side TLS should be reviewed, especially reverse proxies, web servers, API gateways, Internet-facing internal services, and systems with high connection density. NGINX was one example mentioned in Okta testing, but the broader lesson is that every process linked against an older OpenSSL library needs to be checked.
For Linux distributions with backport policies, the displayed version number may not change even when the fix has been included. Looking only at the OpenSSL version string may therefore be insufficient. Operations teams should check package changelogs, vendor advisories, or confirmation that the relevant upstream pull request has been applied.
How to respond in practice
The first priority is to update OpenSSL to a fixed branch or install a distribution package that has backported the fix, then restart services that are still loading the old library. Upgrading the library without restarting processes often leaves services running the unpatched OpenSSL version already in memory.
Organizations should also monitor anomalies in RSS, hanging TLS connection counts, OOM kills, swap pressure, and memory consumption by proxy processes. Connection limits remain useful, but according to the published analysis, limiting connection counts alone may not be enough if each connection leaves behind fragmentation that is hard to reclaim.
The risk-management lesson
HollowByte reinforces an important point: not every risk worth fixing arrives with a prominent CVE label. A change treated as hardening can still make a major operational difference if it blocks a real resource-exhaustion pattern.
For security teams, the right approach is to combine CVE management with release-note tracking, changelog review, research-team intelligence, and behavioral testing of services. For infrastructure teams, the direct lesson is that every foundational library patch such as OpenSSL must come with a controlled restart plan, post-deployment monitoring, and confirmation that running processes have loaded the new version.
VNCyberS compiled from The Hacker News, Okta Red Team, and OpenSSL
Tiếng Việt
English