HollowByte DDoS flaw bloats OpenSSL server memory with 11-byte payload

**HollowByte** is a denial-of-service flaw that lets unauthenticated attackers abuse OpenSSL servers with a malicious payload of only **11 bytes**. The attack does not require credentials or a complex multi-packet sequence: a tiny payload is enough to drive the server into a DoS condition. BleepingComputer reported the issue under the HollowByte name, tying the risk directly to how OpenSSL handles that input.

On the technical side, the core mechanics are memory pressure and asymmetry. The attacker sends a very small request; the server side expands or retains state in a way that **bloats OpenSSL server memory** far beyond the size of the payload. That imbalance is what makes the flaw practical as a DoS vector: cheap input on the client, expensive resource consumption on the host. Because the attacker is unauthenticated, any reachable OpenSSL endpoint that processes the vulnerable path is in scope until it is fixed or shielded.

For engineers and builders, the practical risk is not exotic crypto breakage so much as availability. Services that terminate TLS or otherwise rely on OpenSSL for protocol handling can be pushed toward memory exhaustion and outage with almost no attacker effort. That matters for public-facing APIs, edge proxies, and anything that accepts connections from the open internet without heavy front-end filtering. Memory bloat under load is harder to spot in short load tests than in sustained or adversarial traffic, so operators who only watch CPU or request rate may miss the early signal.

In the wider market and competitive context, OpenSSL remains a default building block across stacks, so a low-cost unauthenticated DoS against it has broad blast radius even when the payload size is trivial. Vendors and maintainers of TLS-terminating products built on OpenSSL face the same class of exposure as hand-rolled servers: the library is shared infrastructure, and the attack cost is low enough that it can be weaponized for noise, ransomware pressure, or competitive disruption. Defenders should treat HollowByte as a capacity and resource-accounting problem as much as a crypto library bug.

Practical takeaway: inventory where OpenSSL terminates or inspects traffic, watch for abnormal memory growth under small or malformed inputs, and prioritize patches or configuration changes that close the HollowByte path once they are available. What to watch next is how quickly maintainers ship fixes, whether edge or WAF rules can cheaply drop the 11-byte pattern without breaking legitimate clients, and whether similar memory-amplification issues surface in adjacent TLS stacks that share design patterns with OpenSSL.