Zum Hauptinhalt springen
S-EDV news
← Alle News
Sicherheit & Datenschutz 21.07.2026 · 3 min Lesezeit

OpenSSL HollowByte: Denial-of-Service per 11-Byte-TLS-Request – Fix ohne CVE und Advisory eingespielt

Eine als HollowByte bekannte OpenSSL-Schwachstelle ermöglicht Angreifern, Linux-Server mit einer einzigen 11-Byte-TLS-Anfrage in einen Denial-of-Service-Zustand zu versetzen – ohne Authentifizierung, ohne CVE-Nummer und ohne offizielles Advisory.

OpenSSL HollowByte Denial of Service Schwachstelle: Server mit Warnsymbol, 11 Byte TLS Request Angriff, Fix ohne CVE eingespielt

Eine als HollowByte bezeichnete Schwachstelle in OpenSSL versetzt Sicherheitsverantwortliche derzeit in Alarmbereitschaft: Angreifer können mit einer präparierten TLS-Anfrage von nur 11 Byte glibc-basierte Linux-Systeme in einen dauerhaften Denial-of-Service-Zustand treiben – ohne jede Authentifizierung. Was die Situation zusätzlich verschärft: OpenSSL hat den Patch „still“ und ohne jede öffentliche Kommunikation eingespielt. Kein CVE, kein Security-Advisory, kein Changelog-Eintrag. Für Unternehmen, die auf automatisiertes Schwachstellenmanagement setzen, ist das eine ernste Herausforderung.

Die Schwachstelle

Sicherheitsforscher haben entdeckt, dass OpenSSL auf glibc-basierten Linux-Systemen durch eine speziell präparierte TLS-Anfrage mit einer Größe von lediglich 11 Byte dazu gebracht werden kann, Speicherressourcen dauerhaft zu blockieren. Der Angriff führt zu einem vollständigen Denial-of-Service: Betroffene Dienste reagieren nicht mehr und müssen neu gestartet werden. Der Name HollowByte verweist auf die minimale Nutzlast, die für den Angriff ausreicht.

Besonders problematisch ist die Voraussetzungslosigkeit des Angriffs: Er erfordert weder Authentifizierung noch spezielle Berechtigungen. Jeder Angreifer mit Netzwerkzugang zum Zielsystem kann den DoS auslösen. Betroffen sind alle Linux-Distributionen, die auf der GNU C Library (glibc) aufbauen – darunter Debian, Ubuntu, RHEL, SUSE und deren Derivate.

Bin ich betroffen?

Systeme sind dann verwundbar, wenn alle folgenden Bedingungen zutreffen:

  1. Das Betriebssystem basiert auf glibc (Debian, Ubuntu, RHEL, CentOS, Rocky Linux, AlmaLinux, SUSE, openSUSE u. a.)
  2. OpenSSL ist installiert und wird für TLS-Verbindungen genutzt
  3. Das System hat noch kein aktuelles OpenSSL-Update erhalten

Da kein CVE zugewiesen wurde und kein offizielles Advisory existiert, lässt sich der Patchstand nicht über herkömmliche Vulnerability-Scanner oder SIEM-Systeme ermitteln. Die einzige zuverlässige Methode ist die direkte Abfrage der installierten OpenSSL-Version:

openssl version

Der aktuelle Patchstand lässt sich außerdem über den jeweiligen Distributions-Paketmanager prüfen:

# Debian / Ubuntu
apt list --installed 2>/dev/null | grep openssl

# RHEL / CentOS / Rocky Linux / AlmaLinux
rpm -q openssl

# SUSE / openSUSE
rpm -q libopenssl3

Wie behebe ich das?

Da kein gesondertes Security-Advisory existiert, ist der einzige Weg zur Absicherung das reguläre System-Update über den Distributions-Paketmanager:

# Debian / Ubuntu
sudo apt update && sudo apt upgrade openssl

# RHEL / CentOS / Rocky Linux / AlmaLinux
sudo dnf update openssl

# SUSE / openSUSE
sudo zypper update libopenssl3

Nach dem Update empfiehlt sich ein Neustart der betroffenen Dienste, da OpenSSL oft dynamisch gelinkt ist und ein laufender Prozess die alte Bibliotheksversion im Speicher halten kann. Ein vollständiger Systemneustart stellt sicher, dass alle Dienste die gepatchte Version verwenden.

Wer seine Linux-Pakete regelmäßig aktuell hält, findet in unserer Anleitung zur Paketverwaltung mit apt und dpkg unter Debian und Ubuntu eine solide Grundlage. Für die allgemeine Serverhärtung empfiehlt sich zusätzlich der Beitrag Linux-Server absichern mit UFW und Fail2ban.

Was bedeutet das für Unternehmen?

HollowByte offenbart ein strukturelles Problem im Umgang mit Sicherheitslücken in weit verbreiteter Open-Source-Software: Wenn ein Projekt einen sicherheitsrelevanten Fix ohne CVE, ohne Advisory und ohne Changelog-Eintrag ausliefert, bricht die gesamte Kette des automatisierten Schwachstellenmanagements zusammen.

Für Unternehmen ergeben sich folgende Handlungsempfehlungen:

  1. Sofortmaßnahme: OpenSSL auf allen Linux-Systemen über den Paketmanager auf den aktuellen Stand bringen
  2. Prozessanpassung: Reguläre System-Updates nicht als optional behandeln, auch wenn kein CVE-Alarm ausgelöst wird
  3. Monitoring: Installierte Paketversionen zentral erfassen und regelmäßig mit Repository-Versionen abgleichen
  4. Awareness: Sicherheitsteams für „stille Fixes“ ohne CVE-Zuordnung sensibilisieren

Wer Systemereignisse auf Linux-Servern gezielt überwachen möchte, findet mit unserer Anleitung Logs lesen mit journalctl und /var/log unter Linux einen guten Einstieg.

Quellen: The Hacker News – OpenSSL HollowByte Flaw Could Freeze Servers | BleepingComputer Security News