Somewhere in Okta’s red team lab in June, someone sent eleven bytes at an OpenSSL server and watched its memory usage climb. Not spike. Climb, steadily, request after request, until the process needed a restart to breathe again. That’s the entire attack: a malformed TLS handshake fragment small enough to fit in a tweet, and on glibc-based systems, it reserves up to 131 KB of memory for a message that never arrives. Do that enough times and you’ve taken a server down without a single exploit chain, privilege escalation, or zero-day fireworks. Okta’s researchers named it HollowByte, and the part that should bother every cybersecurity team paying attention isn’t the bug itself. It’s that OpenSSL had already fixed it in June, quietly, with no CVE, no advisory, and no changelog entry pointing at what it actually did.
Eleven Bytes and a Memory Leak With Manners
HollowByte isn’t sophisticated as far as vulnerabilities go. It’s a resource-exhaustion bug, the kind of thing that used to get filed under “known issue” and forgotten. Send a partial TLS request, one just complete enough that the server commits memory expecting the rest, then never send the rest. Repeat. On the affected glibc builds Okta tested, that allocated memory doesn’t get reclaimed until the process restarts. A handful of connections won’t hurt anyone. An attacker with a script and patience can walk a production server toward denial of service with a fraction of the bandwidth a traditional flood requires.

What makes this a cybersecurity story rather than just a bug report is the disclosure gap. Most teams don’t manually diff every OpenSSL commit. They watch CVE feeds, subscribe to advisories, and let their vulnerability scanners tell them what to prioritize. HollowByte slipped through that whole apparatus. If your patch process is triggered by a CVE number, and no CVE number was ever assigned, your process didn’t trigger. You’re running the fix or you’re not, and you have no idea which, because nothing told you to check.
A Patch That Doesn’t Officially Exist
This isn’t the first time a maintainer has folded a security fix into a routine release without flagging it as one. It happens for reasons that make sense from inside the project: avoiding panic, sidestepping the disclosure paperwork, not wanting to hand attackers a roadmap before adoption catches up. But from the outside, a silent fix is functionally invisible. Threat detection tooling built around CVE identifiers has nothing to detect. Compliance frameworks that require patching within X days of a published CVE have no clock to start. The fix exists in the source tree and nowhere else that most defenders would ever look.
That’s a defense-in-depth failure hiding behind a disclosure failure. If your only line of defense against resource-exhaustion attacks is “the vendor patched it,” you’ve outsourced your threat protection to someone else’s PR description. Teams that actually caught HollowByte early were the ones running their own version audits against upstream source, not the ones waiting for a security bulletin that was never coming.
Meanwhile, Nobody Firewalled the AI Tools Either
The same week HollowByte surfaced, a different kind of blind spot showed up in the wild. A Go-based botnet researchers are calling NadMesh started sweeping the internet for exposed AI infrastructure: ComfyUI instances, Ollama endpoints, n8n workflow builders, Open WebUI deployments, Langflow, Gradio apps. The operator’s own dashboard is reportedly claiming credit for harvesting over 3,800 unique AWS keys. The pattern behind that number is familiar to anyone who’s watched a team move fast: these are the tools people spin up in an afternoon to test a model or wire together an agent workflow, and firewall configuration is the thing that was supposed to happen “later.”

NadMesh isn’t running a novel exploit against these platforms. It’s running Shodan queries against things that were never meant to face the open internet in the first place, then walking through unauthenticated or default-credentialed instances to grab whatever cloud keys and Kubernetes tokens are sitting nearby. Like HollowByte, the vulnerability here isn’t really a vulnerability. It’s a gap between what got deployed and what got secured, and the attacker didn’t need to be clever to find it. They needed to be patient and run a scanner.
Closing the Gap Before Someone Else Finds It
Both stories point at the same operational lesson: don’t let your cybersecurity posture depend entirely on someone else telling you there’s a problem. A few concrete moves apply regardless of what stack you’re running.
Stop tying patch cadence exclusively to CVE feeds. Pull changelogs and diffs directly from the projects you depend on most, especially ones like OpenSSL that sit underneath everything else. Treat “no advisory” as “unverified,” not “safe.” For anything TLS-facing, set connection timeouts and per-source rate limits aggressively enough that a slow-drip resource exhaustion attempt gets cut off before it matters; this is the kind of brute-force pattern that automated IP banning and rate-limiting tools were built to catch, and it costs nothing to enable.
For AI tooling specifically, run an inventory sweep this week, not next quarter. Anything running Ollama, ComfyUI, Open WebUI, n8n, Langflow, or Gradio needs to sit behind authentication and a firewall rule that blocks inbound access from anywhere but your own network, full stop. Rotate any cloud credentials that lived on a box that was ever exposed, even briefly, and check your CloudTrail or equivalent logs for API calls you don’t recognize. That’s not paranoia, it’s incident response you’d rather do proactively than reactively.
Security hardening isn’t a one-time checklist item, it’s the discipline of assuming the advisory you’re waiting for might never arrive. HollowByte and NadMesh are proof that attackers don’t need you to miss a headline. They just need you to trust that someone would have told you if it mattered.
Sources
- OpenSSL HollowByte Flaw Could Freeze Server Memory with 11-Byte TLS Requests
- New NadMesh Botnet Hunts Exposed AI Services for Cloud Keys and Kubernetes Tokens
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
Take Control of Your Server Security
Don't let brute-force attacks slow you down. Try IPBan Pro risk-free for 30 days.
Secure. Automated. Lightweight.
