HollowByte DoS: The Danger of Silent OpenSSL Patches in 2026
It is incredibly frustrating to see OpenSSL shipping critical fixes for memory exhaustion bugs like HollowByte without assigning a CVE or issuing a proper advisory. Okta's recent write-up confirms that a crafted 11-byte TLS request forces an unpatched server to allocate up to 131 KB of memory. On glibc systems, that memory is effectively leaked until the process restarts.
Since this was silently patched in June (likely across the 3.0.x and 3.1.x branches), how are we tracking coverage for this in our scanners? Without a CVE identifier, most automated vulnerability scanners might miss it unless they are specifically checking for the build date or the patched function logic.
We can identify the vulnerable behavior by checking the OpenSSL version build date, as version numbers alone might not tell the full story for intermediate releases:
# Check OpenSSL version and build date
openssl version -a
The exploitation barrier is concerning low. An attacker doesn't need a complex buffer overflow; they just need to blast small TLS packets to trigger the OOM condition.
How are you handling "silent" patches like this in your compliance reporting? Are you manually flagging them based on release dates, or waiting for your scanner vendors to catch up?
We actually caught this during a routine load test last week. Our Nginx ingress controllers were slowly bleeding memory under specific TLS handshake patterns. We upgraded to the latest OpenSSL build just to be safe, but the lack of a CVE made justifying the emergency downtime to management a nightmare.
From a pentester's perspective, this is a gift for DoS testing. The 11-byte payload is tiny enough to slip past basic rate-limiting rules that are looking for large packet sizes.
Here is a quick scapy concept to replicate the packet size:
from scapy.all import *
# Conceptual check for packet size constraints
packet = IP(dst="target")/TCP(dport=443)/Raw(b"A"*11)
print(len(packet))
Definitely verify your glibc tunables.
This highlights a supply chain trust issue. If the core library maintainers are hiding patches to prevent exploit dev before everyone updates, it puts the onus on us to constantly diff changelogs. We are implementing a version check script in our CI/CD pipeline now to flag any OpenSSL build older than June 2026.
Diffing the OpenSSL binaries is the only reliable method right now since changelogs are vague. If you can't patch immediately, consider runtime instrumentation to catch this specific exhaustion pattern. I’ve been using bpftrace to monitor allocation spikes in the OpenSSL process during handshake intervals, which helps distinguish the exploit from normal traffic spikes:
bpftrace -e 'kprobe:malloc /comm == "nginx"/ { @[comm] = hist(args->size); }'
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access