OpenSSL HollowByte: 11 bytes are enough to freeze the memory of a TLS server

An 11-byte TLS request is enough to cause OpenSSL server memory to bloat, leading to a denial of service. A formidable asymmetric DoS.

Facts

Two independent sources (The Hacker News, BleepingComputer) report on July 17, 2026, a vulnerability named HollowByte in OpenSSL. The principle: a TLS request of only 11 bytes causes disproportionate memory allocation on the server side, up to saturation. This is a class of attack known as memory amplification DoS.

• Vector: malformed 11-byte TLS request.
• Effect: memory bloat on the server side (saturated RAM → crash or denial of service).
• Component: OpenSSL, a cryptographic library used by the majority of web servers, VPNs, MTAs, and network tools in the world.

Who is affected

Almost everything that speaks TLS on the Internet and has not yet migrated to a corrected version: Apache/Nginx servers, API backends, reverse proxies, OpenVPN/strongSwan VPNs, mail servers. The critical distinction will be between the affected versions of OpenSSL (LTS 3.x and earlier branches still supported) - to be confirmed on the official advisory openssl.org/news/vulnerabilities.html.

Analysis

A ratio of 11 bytes ➜ several megabytes of RAM is an operational nightmare: the cost for the attacker is ridiculous (one connection, one packet), the cost for the victim is massive (memory, CPU to free, potential crash). This is a classic of asymmetric DoS attacks, a distant cousin of DNS or NTP amplification attacks from the 2010s.

Note: this is not an RCE, not a memory leak like Heartbleed (which exposed data). It is a denial of service. The business consequence: unavailability, not exfiltration. But an API backend that goes down for an hour during peak hours can be very expensive.

The fact that two sources (The Hacker News, BleepingComputer) report the matter a few hours apart on the same day indicates that the OpenSSL advisory is probably already published or imminent. Public PoCs usually follow within 24-48 hours for this type of well-documented vulnerabilities.

What to do now

• Update OpenSSL as soon as the official patch is published (apt update && apt upgrade openssl libssl3 on Debian/Ubuntu, yum update openssl on RHEL).
• Restart dependent services after upgrade (nginx, apache, postfix, openvpn - the lib is loaded in memory).
• Check the version in production: openssl version -a.
• Limit the rate of new TLS connections at the reverse proxy level (Nginx: limit_conn, Cloudflare: rate limiting).
• Monitor the RAM of exposed servers: a sudden spike in OpenSSL RSS can be a sign of exploitation.

What remains to be confirmed

The official CVE number, the exact range of vulnerable versions, and the names of affected variants (BoringSSL, LibreSSL, WolfSSL - forks sometimes share the same bugs) remain to be confirmed on the OpenSSL advisory. We will follow up.