Im Kern vertraute OpenSSL bei älteren Versionen einer Längenangabe, die ein Gegenüber im TLS-Handshake übermittelt. Jede Handshake-Nachricht trägt einen 4-Byte-Header; drei dieser Bytes geben die Länge des Nachrichtentexts an. Laut Okta wurde der Empfangspuffer sofort auf diese deklarierte Größe erweitert, sobald der Header eingetroffen war — noch bevor auch nur ein Byte des Inhalts ankam und bevor die eigentlichen Prüfungen des Handshakes griffen.
Für ein eingehendes ClientHello liegt diese Obergrenze bei 131 KB. Danach blockiert der Worker-Thread und wartet auf einen Nachrichtentext, der nie folgt. Weder Authentifizierung noch Sitzung oder Schlüsselaustausch sind dafür nötig. Für sich genommen wäre das ein klassischer Angriff auf die Verbindungsressourcen, wie man ihn seit Slowloris kennt. Laut Okta wird der Effekt jedoch durch glibc verschärft: OpenSSL gibt den Puffer beim Verbindungsabbruch zwar frei, doch glibc behält kleine und mittlere Speicherbereiche zur Wiederverwendung, statt sie an den Kernel zurückzugeben.
Okta beschreibt, dass ein Angreifer die deklarierte Größe bei jeder Verbindung variiert. In den Tests des Unternehmens reichte das aus, um die Wiederverwendung bereits freigegebener Bereiche zu verhindern. Das Ergebnis seien Heap-Fragmentierung und ein wachsender Resident Set Size, der auch nach Ende des Angriffs erhöht bleibe. In Okta-Tests mit NGINX wurde ein Server mit 1 GB Arbeitsspeicher per OOM-Killer beendet, nachdem 547 MB Speicher in Fragmenten festsaßen. Auf einem 16-GB-Server band HollowByte laut Okta 25 Prozent des Systemspeichers, ohne die Verbindungsobergrenze zu erreichen. Deshalb, so das Red Team, würden „übliche Abwehrmechanismen zur Begrenzung von Verbindungen es nicht stoppen“.
Die Korrektur steckt in OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 und 3.0.21, alle datiert auf den 9. Juni. Dennoch fehlt jede übliche Kennzeichnung. Matt Caswell, der den Patch geschrieben hat, formulierte im Pull Request, das Sicherheitsteam habe sich entschieden, dies nur „als Fehler- oder Härtungs-Fix“ zu behandeln. OpenSSLs eigene Sicherheitsrichtlinie kennt laut Quelltext vier Schweregrade von Kritisch bis Niedrig; „Fehler oder Härtung“ gehört nicht dazu. Selbst ein Problem mit niedrigem Schweregrad erhalte normalerweise eine CVE, einen Changelog-Eintrag und eine Erwähnung auf der Schwachstellenseite. The Hacker News fand keine dieser drei Spuren und auch keinen Hinweis in den Release Notes oder in den 23 Einträgen des Changelogs von OpenSSL 4.0.1.
Zum Vergleich verweist der Quelltext auf andere Speichererschöpfungsfehler, die sehr wohl eine Kennzeichnung erhielten. Im Januar vergab OpenSSL CVE-2025-66199 mit Schweregrad Niedrig für einen Fehler bei der Zertifikatskomprimierung in TLS 1.3, bei dem eine vom Gegenüber gelieferte Länge einen Heap-Puffer vor der Validierung vergrößerte; dort waren rund 22 MiB pro Verbindung möglich. Die Releases vom 9. Juni enthielten außerdem CVE-2026-34183, als Moderat eingestuft, wegen unbegrenzten Speicherwachstums im QUIC-PATH_CHALLENGE-Handler. Beide Fälle betreffen Denial-of-Service durch Speicherverbrauch, beide erhielten Kennungen.
Für nachgelagerte Distributionen wird die Lage laut Quelltext komplizierter. Red Hat dokumentiert standardmäßig Backporting statt Versionssprünge, sodass ein gepatchtes Paket weiter die ursprüngliche Versionsnummer meldet. Normalerweise helfen Advisorys und OVAL-Feeds, die an CVE-Namen gekoppelt sind. Hier fehlt diese Referenz. Damit bleiben laut Quelltext im Wesentlichen nur Paket-Changelog oder Rückfrage beim Maintainer. Genannt werden die Pull Requests 30792 für Master und 4.0, 30793 für 3.6, 3.5 und 3.4 sowie 30794 für 3.0. Wer OpenSSL selbst baut, soll auf die genannten Releases wechseln und die Prozesse neu starten, die die alte Bibliothek geladen haben.
Die Korrektur betrifft nur TLS. Caswell schrieb im Pull Request, DTLS sei unverändert geblieben, weil eine saubere Behebung deutlich invasiver gewesen wäre und das Projekt sich vorerst dagegen entschieden habe. The Hacker News verglich den OpenSSL-Quelltext zwischen den Tags 3.6.2 und 3.6.3 und stellte fest, dass die DTLS-Handshake-Datei über den Fix hinweg byteidentisch blieb. In 4.0.1, dem neuesten Release, dimensioniert dieser Pfad den Puffer demnach weiterhin nach der vom Gegenüber deklarierten Länge. OpenSSL hat diesen Pfad laut Quelltext weder klassifiziert noch eine Behebung zugesagt.