OpenSSL-Sicherheitslücke CVE-2026-84782: Was Rootserver- und Webhosting-Betreiber jetzt aktualisieren sollten

Ein Update, das installiert ist, aber nie geladen wurde, schützt dich exakt so gut wie gar keins. Genau diese Falle ist bei OpenSSL-Lücken der Klassiker, und deshalb lohnt sich ein genauer Blick auf das Advisory vom 29. September 2026.

Was genau passiert ist

Das OpenSSL-Projekt hat zum 29. September 2026 ein Sicherheitshinweis veröffentlicht und gleichzeitig korrigierte Versionen freigegeben. Günter Born hat darüber am 2. Oktober 2026 in seinem Blog berichtet, auch The Hacker News hat das Thema aufbereitet. Es geht um CVE-2026-84782, bewertet mit 8.8 nach CVSS 3.x, also "high".

Der Fehler heißt im Advisory "DTLS Retransmits Handshake Messages From a Stale Buffer Offset". Vereinfacht: DTLS ist die Variante von TLS für verbindungslose Übertragung (UDP). Geht beim Handshake etwas verloren, sendet OpenSSL Nachrichten erneut. Wurde ein Schreibvorgang für eine Handshake-Nachricht mittendrin unterbrochen, verarbeitet die Retransmit-Logik das nicht korrekt. Zwei Dinge gehen schief:

• Lesen über das Ziel hinaus: Die erneut gesendete Nachricht kann über den Nachrichtenpuffer hinauslesen. Das Gegenüber bekommt dann Heap-Speicher als Klartext-Handshake-Daten zu sehen.
• Zustand überschrieben: Die Wiederholung überschreibt den internen Zustand, den der unterbrochene Schreibvorgang zum korrekten Fortsetzen braucht.
• Absturz: Erreicht der Lesevorgang einen nicht zugeordneten Speicherbereich, stürzt der Prozess ab. Das reicht für einen Denial-of-Service.

Heap-Speicher kann alles Mögliche enthalten, was der Prozess gerade verarbeitet hat. Was im konkreten Fall herausläuft, lässt sich nicht vorhersagen. Genau deshalb solltest du solche Lücken nicht schönrechnen.

Welche Versionen betroffen sind und worauf du aktualisierst

Betroffen sind gleich sieben Zweige. Die Fixstände laut Advisory:

Bin ich überhaupt betroffen?

Ein klassischer Webserver mit HTTPS spricht TLS über TCP, kein DTLS. Daraus darfst du aber nicht ableiten, dass dich das nichts angeht. Auf einem Rootserver laufen oft mehr Dienste, als man im Kopf hat: VPN-Software, Medien- und Telefonie-Server, IoT-Gateways. Manche davon nutzen DTLS. Ob ein Dienst DTLS-Verkehr annimmt, steht in seiner Dokumentation und in den offenen UDP-Ports.

Unser Rat: Aktualisiere die Bibliothek trotzdem überall. Der Aufwand ist klein, das Risiko bei Auslassen schwer abzuschätzen. Wer auf seinem Rootserver ein VPN betreibt, sollte das Thema ohnehin ganz oben auf die Liste setzen.

Schritt für Schritt: prüfen, updaten, verifizieren

1. Version feststellen. Zuerst schaust du, was das System als OpenSSL führt:

   openssl version -a

2. Offene UDP-Dienste auflisten. So erkennst du, welche Programme überhaupt DTLS sprechen könnten:

   ss -ulpn

3. Paketquellen aktualisieren und installieren. Unter Debian oder Ubuntu:

   apt update
   apt install --only-upgrade openssl libssl3

   Der Paketname der Bibliothek hängt von deiner Distribution ab. Bei RHEL-Derivaten nimmst du dnf upgrade openssl.
4. Betroffene Prozesse finden. Prozesse, die noch die alte Bibliothek im Speicher halten, zeigt dir das Tool needrestart oder, ohne Zusatzpaket:

   grep -l 'libssl.*(deleted)' /proc/*/maps 2>/dev/null

5. Dienste neu starten. Starte alles neu, was in Schritt 4 auftaucht, zum Beispiel:

   systemctl restart nginx

   Im Zweifel hilft ein Neustart des gesamten Servers.
6. Selbst gebaute Software prüfen. Wurde ein Programm statisch gegen OpenSSL gebaut oder bringt es eine eigene Kopie mit (viele Container-Images tun das), hilft das Systemupdate nicht. Dann brauchst du ein neu gebautes Image oder eine neue Programmversion.

So prüfst du, dass es geklappt hat

Eine Version-Ausgabe allein reicht nicht, denn viele Distributionen übernehmen Fixes in ihre bestehende Versionsnummer. Prüf deshalb zwei Dinge:

• Changelog des Pakets: apt changelog openssl zeigt, ob CVE-2026-84782 dort genannt wird.
• Geladene Bibliothek: Nach dem Neustart darf die Prüfung aus Schritt 4 keine Treffer mehr liefern.
• Erreichbarkeit der Dienste: Teste VPN, Webserver und Mail kurz durch. Ein Neustart, der einen Dienst nicht wieder hochbringt, fällt sonst erst auf, wenn jemand sich beschwert.

Eine Lücke ist erst geschlossen, wenn der laufende Prozess den neuen Code geladen hat, nicht wenn das Paket installiert ist.

Was das für Webhosting-Kunden bedeutet

Nutzt du Webhosting, also keinen eigenen Server, kümmert sich der Anbieter um die Systembibliotheken. Du musst nichts installieren. Anders sieht es aus, wenn du Webhosting selbst auf einem Rootserver betreibst, etwa mit einem Panel: Dann bist du für das Betriebssystem verantwortlich. Wie das aussieht, zeigt unsere Seite zu Webhosting auf dem Rootserver. Zu Panels haben wir zuletzt auch den Beitrag Froxlor-Sicherheitslücken geschrieben. Dort gilt dasselbe Prinzip: Regelmäßig aktualisieren, bevor jemand die Lücke ausnutzt.

Häufige Fehler

• Nur das Paket aktualisiert: Ohne Neustart der Dienste läuft der verwundbare Code weiter.
• Nur den Host im Blick: Container, Chroots und selbst kompilierte Programme haben eigene Kopien.
• Versionsnummer falsch gelesen: 3.0.23 aus dem Advisory und die Nummer deiner Distribution müssen nicht übereinstimmen. Entscheidend ist der Changelog-Eintrag.
• Zu lange gewartet: Das Advisory ist öffentlich, und genau das Zeitfenster danach nutzen Angreifer gern.

Wenn du ohnehin am System arbeitest, nimm gleich noch den Zugang mit: Wie du SSH mit Schlüsseln und fail2ban absicherst, steht in einem eigenen Beitrag.