In June 2024, OpenSSL released version 3.3.1 containing a fix for what Okta's security team later named HollowByte, a flaw that lets an attacker freeze server memory with minimal TLS requests. You wouldn't know it from reading the release notes. There was no CVE assignment, no security advisory, and no changelog entry. The fix appeared as a commit with no indication it addressed a denial-of-service vulnerability.
Okta discovered this when their NGINX testing showed a 1 GB server getting OOM-killed with 547 MB of memory frozen in fragments. That's a production-grade impact from a bug OpenSSL classified as "hardening" rather than a vulnerability.
What Happened
HollowByte exploits how OpenSSL allocates memory during TLS handshakes. An attacker sends specially crafted 11-byte TLS requests that trigger memory allocations without corresponding deallocations. The issue compounds when glibc's memory allocator behavior kicks in, holding freed memory in fragments and making it unavailable for other processes.
The attack doesn't require authentication or complex exploitation. You send requests, memory fragments accumulate, and eventually the server runs out of available memory despite the process showing freed space.
OpenSSL's team decided this didn't meet their threshold for vulnerability classification. They treated it as a bug fix and merged the patch without public disclosure.
Timeline
June 2024: OpenSSL releases version 3.3.1 with the fix committed as routine code changes. No security-related metadata accompanies the release.
Post-release: Okta's security researchers, conducting unrelated NGINX testing, identify the memory exhaustion behavior. They trace it to OpenSSL's memory handling and discover the silent fix in 3.3.1.
Public disclosure: Okta publishes their findings, naming the flaw HollowByte and documenting the practical impact on production systems.
Which Controls Failed
Your vulnerability management process assumes upstream projects will flag security-relevant changes. That assumption broke here. The specific failures:
No vendor communication: OpenSSL didn't classify this as security-relevant, so no advisory reached your security team's monitoring channels.
Changelog opacity: The release notes contained no indication that a DoS condition had been addressed. Your team reviewing changelogs for upgrade planning would miss this entirely.
CVE absence: Your vulnerability scanners, SBOM tools, and compliance reporting all key off CVE identifiers. Without one, this fix doesn't appear in your remediation workflows.
Dependency blindness: If you run NGINX, HAProxy, or any TLS-terminating service using OpenSSL, you're affected. But your dependency scanning tools won't flag this because there's no vulnerability record to match against.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.1 says you must identify security vulnerabilities using reputable sources and assign a risk ranking. When your "reputable source" ships a fix without marking it as security-relevant, you can't comply with this requirement as written. Your risk ranking process depends on the vendor telling you something is a vulnerability.
ISO/IEC 27001:2022 Control 8.8 (Management of technical vulnerabilities) requires you to obtain timely information about technical vulnerabilities. "Timely" assumes the information exists in a discoverable form. A commit buried in a routine release doesn't meet this bar.
NIST CSF v2.0 function Detect (DE.CM-8) expects you to perform vulnerability scans and monitor for unauthorized changes. Your scans look for known vulnerabilities. This wasn't marked as one, so your detective controls didn't fire.
The standards assume a working vulnerability disclosure ecosystem. When that ecosystem breaks down, when a project ships a DoS fix as "hardening", your compliance posture depends on luck and third-party researchers.
Lessons and Action Items
Stop trusting changelogs alone. Your patch review process needs to include commit-level analysis for critical dependencies. Set up monitoring on the OpenSSL GitHub repository. Watch for commits that touch memory allocation, buffer handling, or request processing, regardless of how they're categorized.
Expand your vulnerability intelligence sources. You can't rely on CVE feeds. Add security research blogs, vendor security teams (like Okta's), and project mailing lists to your monitoring. When Okta publishes findings about OpenSSL, that's your signal to investigate, not wait for a CVE.
Test your own DoS resilience. Okta found this through testing. You should be running similar tests. Spin up a staging environment that mirrors production and send malformed TLS requests. Monitor memory usage patterns. If your server's memory fragments under load, you've got a problem whether or not it has a CVE.
Document your dependency risk posture. Your auditor will ask how you knew to apply this patch. "We upgraded to 3.3.1 for other reasons" isn't a satisfying answer. Build a record showing you monitor commit activity, review security research, and have a process for evaluating non-CVE security changes.
Pressure your vendors for better disclosure. If you're an OpenSSL stakeholder (and you are, if you run any TLS service), you have standing to request better vulnerability classification. The current approach, where a DoS fix with documented production impact doesn't get flagged, creates compliance gaps your team has to fill manually.
Adjust your SBOM tooling expectations. Your software bill of materials tools track CVEs. They won't catch this. You need supplementary processes: manual review of critical component updates, security research monitoring, and testing protocols that don't depend on vulnerability databases.
The HollowByte case isn't about one bug. It's about what happens when the infrastructure you've built for vulnerability management, scanners, SBOMs, compliance checklists, assumes vendors will use standard disclosure channels. When they don't, you're left reverse-engineering commit logs to figure out if you're exposed.
Your compliance framework says "identify and remediate vulnerabilities." It doesn't say "identify and remediate things that vendors choose to call vulnerabilities." Close that gap now, because HollowByte won't be the last silent fix that lands in your production stack.
