The OpenSSL Fix That Arrived with No CVE. NIS2 Still Expects You to Patch It.

On June 9, 2026, OpenSSL released versions 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. One of those fixes addressed a denial-of-service condition that Okta's Red Team would later name HollowByte. OpenSSL did not issue a CVE. OpenSSL did not publish a security advisory. The changelog contains no entry pointing to a security issue. OpenSSL classified the change as "bug or hardening."

Six weeks later, on July 17, 2026, Okta published the details. An attacker sends 11 bytes. The server allocates up to 131 KB for a message body that never arrives. On glibc-based Linux systems, that memory does not come back after the attacker drops the connection. Run enough of those requests and you OOM-kill the server. Standard connection-limiting defenses - rate limits, connection counts, timeouts - do not stop it.

For most security teams, the story ends there: patch to the fixed version, move on. But there is a second problem inside this one that does not resolve by patching. If your organization is subject to NIS2 or DORA, you have documented patch management obligations tied to "known vulnerabilities." HollowByte is a known issue now. Your scanner does not know that. Your compliance program does not know that either.

What OpenSSL Actually Shipped (and Didn't Say)

OpenSSL has a published security policy. Under that policy, even a Low severity vulnerability earns a CVE. There is no severity category below Low that is still a security issue. The policy is explicit: if it is a security bug, it gets a CVE.

HollowByte has no CVE. OpenSSL's classification - "bug or hardening" - puts it outside the security policy entirely. That is not a technicality. It is a deliberate classification decision that has direct downstream effects on every organization that depends on CVE-based tooling to drive patch decisions.

The GitHub pull request from Matt Caswell (PR #30792) contains the actual fix. It exists. The code change is there. But unless you are monitoring OpenSSL's GitHub repository at the commit level and reading individual pull request descriptions, you would have had no way to know that a June 9 release addressed a remotely exploitable memory issue. The release notes do not tell you. The advisory feed does not tell you. The CVE database does not tell you.

The fix was available 38 days before anyone publicly described what it fixed.

How HollowByte Works

The mechanism is straightforward. A TLS client sends an initial 11-byte request. The server reads this as the beginning of a larger TLS record and allocates a buffer - up to 131 KB - to hold the rest of the message body that the client indicated was coming. The client then drops the connection without sending anything else.

On a standard Linux system using glibc, that allocated buffer does not get returned to the operating system. It stays resident in the process's heap. The next request allocates another one. Run this in a loop and the server's memory fills up. There is no connection kept open - each request completes and terminates. The fragmented heap space simply does not get reclaimed.

In Okta's NGINX testing, a 1 GB server was OOM-killed with 547 MB of memory frozen from these orphaned allocations. A 16 GB server lost 25% of system memory without triggering connection-count-based defenses, because each individual connection behaves normally from the network's perspective - it connects, sends a small packet, and disconnects.

Okta's Red Team stated it directly: standard connection-limiting defenses won't stop it. The attack does not look like an attack at the connection layer. It looks like a series of clients connecting briefly and leaving. The damage accumulates in the process's memory heap, invisible to the controls most organizations rely on.

As of July 18, 2026, no public proof-of-concept code had been published. That changes nothing about the risk. The mechanism is described in enough detail that building an exploit is a scripting exercise, not a research project.

The Patch Management Gap NIS2 and DORA Don't Address

NIS2 (Directive 2022/2555) requires organizations in scope to implement patch management as part of cybersecurity risk management under Article 21. The directive uses the phrase "vulnerability handling and disclosure" as a named control area. DORA (Regulation 2022/2554) requires financial entities to maintain ICT risk management frameworks that include patch management under Articles 9 and 13.

Both frameworks assume a working model: a vulnerability exists, it gets a CVE or equivalent identifier, your scanner picks it up, your patch policy triggers, the fix gets deployed. This model is how most patch management programs are actually built. Scan, prioritize by CVSS, remediate by SLA, document, close the ticket.

HollowByte breaks that model at the first step. There is no CVE. There is no NVD entry. There is no scanner signature to match. If your patch policy says "deploy critical and high CVEs within 30 days," HollowByte does not enter the queue. It does not exist in the queue. The policy executed correctly and left you exposed.

This is not an edge case. It is a predictable failure mode for any patch management program that treats CVE presence as the entry condition for the remediation workflow. Vendors routinely ship security fixes without CVE assignment - either because they do not consider it a security issue, because the CVE process has a backlog, or because the fix was bundled into a routine update without a separate security disclosure. OpenSSL has a better security disclosure process than most vendors. HollowByte still slipped through their own policy.

The compliance question is uncomfortable. NIS2 requires patch management for "known vulnerabilities." Is HollowByte a known vulnerability? After July 17, 2026, yes. Before that, the only people who knew it existed were inside OpenSSL and possibly Okta. Your compliance dashboard was accurate - you had no flagged unpatched vulnerabilities - and you were running unpatched software with a known exploitable condition.

NIS2 and DORA do not define the boundary between "known" and "unknown" in a way that resolves this. The regulations require you to have a patch management process. They do not require the process to function when the vendor does not disclose what it fixed. That gap is yours to close.

What CISOs Should Do Now

Patch first. If you are running OpenSSL prior to 4.0.1, 3.6.3, 3.5.7, 3.4.6, or 3.0.21, update now. This is not a complex remediation. The fixed versions were available on June 9, 2026. Whether the 1.1.1 and 1.0.2 extended support branches received the fix is still unconfirmed as of July 18, 2026 - if you are on those branches, contact your support provider today.

Add vendor release monitoring to your patch process. CVE-based scanning is necessary but not sufficient. For critical components - TLS libraries, web servers, authentication middleware, anything in the path of external traffic - your patch management process needs a second trigger: "new version released." This does not mean automatically patching every release. It means reviewing release notes for every version of critical components, looking for security-relevant changes even when they are not labeled as such.

For OpenSSL specifically, that means monitoring the GitHub repository at github.com/openssl/openssl/releases and reviewing individual commits and pull requests when a release contains changes classified as "bug" or "hardening." This is more work than CVE scanning. It is also the only way to catch what CVE scanning misses.

Document the gap in your NIS2 and DORA compliance program. If you are subject to either regulation, your patch management policy probably has CVE coverage as the primary mechanism. That policy has a documented gap. Acknowledging it is better than leaving it unaddressed - regulators respond better to organizations that identify and close known process weaknesses than to organizations where the gap only surfaces during an incident investigation.

The documentation should cover: what triggered discovery (in this case, an external researcher publication), when the fix became available (June 9, 2026), when your organization applied it, and what process change prevents a recurrence. That is the record that demonstrates functioning vulnerability management under both NIS2 Article 21 and DORA Articles 9 and 13.

Review your OpenSSL inventory. OpenSSL is embedded in a wide range of products beyond direct deployments. Web servers, VPN appliances, load balancers, authentication systems, and cloud provider SDKs all commonly link against OpenSSL. Your direct OpenSSL installations may be patched while a vendor product bundles an older version. Check the OpenSSL version in use across your environment, not just in the components you own directly.

On the 1.1.1 and 1.0.2 branches specifically - if you are still running either, you already have a compliance problem separate from HollowByte. OpenSSL 1.1.1 reached end-of-life in September 2023 and 1.0.2 in December 2019. Running EOL cryptographic libraries is a documented finding in NIS2 and DORA contexts regardless of whether a specific CVE applies.