OpenSSL HollowByte Flaw Lets Attackers Drain Server Memory With an 11-Byte Request

A denial-of-service vulnerability called HollowByte can allow an unauthenticated attacker to consume substantial server memory by sending an incomplete TLS request containing as little as 11 bytes.

The Okta Red Team, which discovered the issue, found that affected OpenSSL versions allocate memory based on a size declared by the attacker before receiving the complete TLS handshake message.

Repeated requests can increase memory use, occupy connections and eventually make an exposed service unresponsive. On Linux systems using glibc, memory fragmentation can amplify the impact because the allocator may retain freed memory instead of returning it immediately to the operating system.

How the OpenSSL HollowByte attack works

A TLS connection begins with a record header followed by handshake data. The TLS record header is 5 bytes long, while each handshake message starts with a separate 4-byte header that includes a 3-byte length field.

An attacker can declare a large handshake message in this header but send only a small part of it. Older OpenSSL code may expand its initial receive buffer according to the declared length before the rest of the message arrives.

The OpenSSL correction for the main and 4.0 branches changed this behavior. OpenSSL now grows the buffer incrementally as it receives data rather than allocating the full advertised amount in advance.

Attack stage	What happens
Connection begins	The attacker opens a connection to a service that accepts TLS traffic.
Length is declared	A crafted handshake header claims that a much larger message will follow.
Buffer expands	An affected OpenSSL build allocates memory based on the declared length.
Data stops	The attacker withholds the remaining handshake data, leaving the connection incomplete.
Attack repeats	Many requests consume connections and create memory pressure on the server.

Memory fragmentation can increase the damage

A single HollowByte connection can cause an affected process to reserve up to roughly 131 KB, according to the researchers. That amount may appear small, but an attacker can create many connections while sending very little data.

Closing those connections does not guarantee an immediate reduction in the process’s resident memory. On systems using glibc, the allocator can keep freed memory available for future allocations instead of returning it directly to the operating system.

The HollowByte research found that varying the requested allocation sizes made memory reuse less efficient. This produced fragmentation and allowed the process’s resident set size, or RSS, to remain high after attack connections closed.

• In a test environment with 1 GB of RAM, the affected server accumulated about 547 MB of retained memory before the operating system terminated it.
• In a 16 GB environment, the attack tied up approximately 25% of system memory without exceeding the configured connection ceiling.
• Restarting the affected process released memory that the allocator had retained during testing.

Connection limits may not fully stop HollowByte

HollowByte shares some characteristics with slow-connection attacks, but it adds a memory allocation component. Traditional connection limits can reduce exposure, yet they may not stop an attacker from creating damaging memory pressure below those limits.

TLS handshake timeouts, per-IP connection limits and reverse proxies can make exploitation harder. Administrators should treat these controls as additional protection, not as substitutes for installing a corrected OpenSSL version.

Attack impact will vary according to the application, operating system, allocator, worker model, resource limits and TLS timeout settings. The issue does not guarantee that every OpenSSL-based service will crash after receiving a single 11-byte request.

Which OpenSSL versions contain the fix?

OpenSSL included the correction in updates released on June 9, 2026. The project’s official release and advisory timeline confirms that OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 and 3.0.21 arrived on that date.

OpenSSL branch	Version containing the HollowByte fix
4.0	4.0.1
3.6	3.6.3
3.5	3.5.7
3.4	3.4.6
3.0	3.0.21

The project implemented the change through pull requests covering different supported branches. The incremental buffer allocation patch covers the main and OpenSSL 4.0 code, while related backports address the 3.x branches.

OpenSSL did not assign HollowByte a CVE identifier or identify it as a separate vulnerability in the June security advisory. Its absence from CVE-based scanners means administrators should check package versions directly rather than relying only on vulnerability alerts.

What server administrators should do

Organizations should upgrade to a fixed OpenSSL release supplied by their operating system or software vendor. After installing the update, administrators must restart services that loaded the old OpenSSL library into memory.

The official OpenSSL release timeline can help teams confirm the upstream release dates, but vendor package numbers may differ. Linux distributions often backport security corrections without adopting the same upstream version number.

• Inventory internet-facing services that terminate TLS connections.
• Check both dynamically linked and bundled OpenSSL copies.
• Update to OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 or 3.0.21, as appropriate.
• Ask the vendor whether its package includes the HollowByte incremental buffer allocation patch.
• Restart web servers, proxies, databases and application runtimes after patching.
• Monitor RSS growth, incomplete TLS handshakes and unusual connection patterns.
• Apply sensible handshake timeouts and per-client connection limits as additional safeguards.

Administrators should also inspect applications that bundle their own cryptographic libraries. Updating the operating system’s OpenSSL package will not replace a private copy embedded in a container, appliance, runtime or statically linked application.

FAQ