Am 29. September hat das OpenSSL-Projekt Sicherheitsupdates veröffentlicht, die die hochgradige Schwachstelle CVE-2026-84782 im Mechanismus zur Retransmission von DTLS-Nachrichten beheben. Der Fehler ermöglicht es, den Inhalt des Heap-Speichers eines Prozesses an die entfernte Seite in Form unverschlüsselter Handshake-Daten zu übermitteln oder einen Programmabsturz auszulösen. Die Schwachstelle betrifft alle Hauptzweige von OpenSSL – von 1.0.2 bis 4.0 – allerdings nur Anwendungen, die OpenSSL explizit für DTLS-Verbindungen einsetzen. Normale TLS-Deployments sind von diesem Problem nicht betroffen. Behebungen stehen in den Versionen OpenSSL 4.0.3, 3.6.5, 3.5.9 und 3.4.8 sowie in den Paketen von Ubuntu und Debian zur Verfügung.
Mechanismus der Schwachstelle
DTLS (Datagram Transport Layer Security) ist eine Variante von TLS für UDP-Traffic, beschrieben in RFC 9147. Sie wird unter anderem zum Schutz von WebRTC-Datenkanälen und zur Aushandlung von Verschlüsselungsschlüsseln bei Internet-Telefonie eingesetzt. Da UDP keine Zustellung garantiert, implementiert DTLS einen eigenen Mechanismus für erneutes Senden: Wenn auf eine Handshake-Nachricht bis zum Ablauf eines Timers keine Antwort eintrifft, wird die Nachricht erneut gesendet.
Große Handshake-Nachrichten werden von DTLS in Fragmente aufgeteilt, von denen jedes in ein einzelnes UDP-Datagramm passt. Wenn eine Verbindung vorübergehend keine Daten empfangen kann, wird der Versand mitten in einer Nachricht angehalten. Laut der Beschreibung im CISA-ADP-Eintrag entsteht das Problem, wenn der Retransmission-Timer genau in dem Moment auslöst, in dem die Aufzeichnung einer größeren Handshake-Nachricht auf halber Strecke pausiert ist. Vor der Behebung nutzte der Retransmission-Code die aktuelle Position der pausierten Nachricht im Puffer, anstatt zum Anfang der erneut zu sendenden Nachricht zurückzukehren. Infolgedessen erhielt die erneut gesendete Nachricht eine falsche Kennzeichnung, und ihr Inhalt bestand aus den verbleibenden Bytes aus dem Puffer der größeren Nachricht, wobei das Lesen über die Puffergrenzen hinausgehen konnte.
Das führt zu zwei Konsequenzen: Der Inhalt des Heap-Speichers kann an die entfernte Seite als unverschlüsselte Handshake-Daten übermittelt werden, und wenn das Lesen einen nicht abgebildeten Speicherbereich erreicht, stürzt der Prozess ab.
Bewertung der Schwere
Das OpenSSL-Projekt stuft CVE-2026-84782 gemäß der Beschreibung zum Release 3.4.8 als Schwachstelle mit dem Schweregrad High ein – eine Stufe unter Critical auf der eigenen Skala. CISA ADP hat die Bewertung CVSS 3.1 – 8.2 (High) mit dem Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H vergeben und weist auf eine geringe Auswirkung auf die Vertraulichkeit und eine hohe Auswirkung auf die Verfügbarkeit hin. Wichtig ist, dass OpenSSL CVSS nicht zur Ermittlung der eigenen Schweregrade nutzt und darauf hinweist, dass Bewertungen externer Organisationen deutlich abweichen können.
Zum Zeitpunkt der Veröffentlichung des Eintrags am 29. September hat CISA den Ausnutzungsstatus als „none“ vermerkt. Unabhängige öffentliche Berichte über eine Ausnutzung der Schwachstelle wurden nicht gefunden. OpenSSL hat dabei nicht präzisiert, ob ein Angreifer gezielt eine Retransmission genau in dem Moment provozieren kann, in dem die Aufzeichnung einer Nachricht pausiert ist.
Betroffener Bereich
Der praktische Wirkungsbereich ist geringer, als es die Anzahl der betroffenen Versionen vermuten lässt. Die Schwachstelle tritt nur auf, wenn gleichzeitig zwei Bedingungen erfüllt sind: Die Anwendung nutzt OpenSSL für DTLS (und nicht für normales TLS), und die Aufzeichnung einer Handshake-Nachricht ist genau in der Mitte pausiert, wenn der Retransmission-Timer auslöst. Deployments, die ausschließlich TLS über TCP verwenden, sind von diesem Problem nicht betroffen. OpenSSL beschränkt die Schwachstelle nicht auf Clients oder Server – die Behebung wurde in beiden Rollen getestet.
Am stärksten gefährdet sind Systeme, die DTLS intensiv nutzen: WebRTC-Server, VoIP-Infrastrukturen, VPN-Lösungen auf Basis von UDP und IoT-Geräte mit DTLS-Kanälen.
Betroffene Versionen und Behebungen
Nach Angaben der CNA betrifft die Schwachstelle die folgenden OpenSSL-Versionen:
- OpenSSL 4.0.0 – 4.0.2 → behoben in 4.0.3
- OpenSSL 3.6.0 – 3.6.4 → behoben in 3.6.5
- OpenSSL 3.5.0 – 3.5.8 → behoben in 3.5.9
- OpenSSL 3.4.0 – 3.4.7 → behoben in 3.4.8
- OpenSSL 3.0.0 – 3.0.22 → behoben in 3.0.23 (nur kostenpflichtiger Support)
- OpenSSL 1.1.1 bis 1.1.1zj → behoben in 1.1.1zj (nur kostenpflichtiger Support)
- OpenSSL 1.0.2 bis 1.0.2zs → behoben in 1.0.2zs (nur kostenpflichtiger Support)
Der Zweig 3.0 erhält seit dem 7. September keine öffentlichen Sicherheitsupdates mehr. Version 3.0.23 war das erste Update dieses Zweigs, das nicht öffentlich verfügbar ist. Für alle, die OpenSSL 3.0 selbst kompilieren oder in ihre Produkte integrieren, empfiehlt OpenSSL den Umstieg auf einen neueren Zweig (4.0 oder den LTS-Release 3.5) oder den Abschluss eines kostenpflichtigen Supportvertrags.
Die Linux-Distributionen haben zeitnah Updates bereitgestellt. Laut dem ursprünglichen Bericht hat Ubuntu am 29. September Behebungen veröffentlicht:
- Ubuntu 26.04 LTS: libssl3t64 3.5.5-1ubuntu3.6
- Ubuntu 24.04 LTS: libssl3t64 3.0.13-0ubuntu3.16
- Ubuntu 22.04 LTS: libssl3 3.0.2-0ubuntu1.30
Debian hat die Schwachstelle in Debian 13 mit dem Paket openssl in Version 3.5.7-1~deb13u3 (DSA-6531-1) behoben. Zum Stand 07:36 UTC am 30. September vermerkte der Sicherheitstracker von Debian Debian 12 weiterhin als verwundbar.
Weitere Schwachstellen in diesem Release
Neben CVE-2026-84782 beheben die Releases vom 29. September noch 13 weitere Schwachstellen. Zwei davon verdienen besondere Beachtung:
CVE-2026-84783 – eine Use-after-free-Schwachstelle, die nur OpenSSL 4.0 betrifft. Ein entfernter, nicht authentifizierter Teilnehmer kann einen Absturz eines Multithread-TLS-Clients oder eines Multithread-TLS-Servers, der Client-Zertifikate anfordert, auslösen, wenn mehrere Verbindungen gleichzeitig die ersten Zertifikatsketten zu derselben vertrauenswürdigen CA aufbauen. Hervorzuheben ist die Diskrepanz in den Bewertungen: Das OpenSSL-Projekt ordnet ihr den Schweregrad Moderate zu, während CISA ADP sie mit CVSS 3.1 7.5 (High) einstuft.
CVE-2026-75806 – eine Schwachstelle geringen Schweregrads in DTLS 1.2, laut Beschreibung des OpenSSL-Releases. Jeder, der ein Datagramm an eine bestehende DTLS‑1.2‑Verbindung mit AEAD-Chiffersuite senden kann, ist in der Lage, diese mit einem einzigen zu kurzen Datagramm zu trennen, ohne die Schlüssel zu kennen. Die übrigen 11 Schwachstellen sind ebenfalls als Low eingestuft und umfassen 5 Fehler im QUIC-Code und 3 Timing-Side-Channel-Schwachstellen im Code von ECDSA und SM2.
Empfehlungen
- Aktualisieren Sie OpenSSL auf die Versionen 4.0.3, 3.6.5, 3.5.9 oder 3.4.8, abhängig vom verwendeten Zweig. Die Sicherheitsrichtlinie von OpenSSL empfiehlt, Updates mit dem Schweregrad High so schnell wie möglich zu installieren.
- Für Ubuntu-Nutzer: Installieren Sie die aktualisierten libssl-Pakete und führen Sie einen Neustart durch – laut Ubuntu ist dies für die vollständige Anwendung der Änderungen erforderlich.
- Für Nutzer von Debian 12: Verfolgen Sie das Erscheinen einer Behebung im Sicherheitstracker.
- Für Nutzer von OpenSSL 3.0: Planen Sie die Migration auf einen unterstützten Zweig (3.5 LTS oder 4.0), da öffentliche Updates für 3.0 eingestellt wurden.
- Führen Sie ein Audit der DTLS-Nutzung in Ihrer Infrastruktur durch – wenn OpenSSL ausschließlich für TLS über TCP eingesetzt wird, betrifft Sie diese konkrete Schwachstelle nicht.
Für alle, die nicht aktualisieren können, bietet OpenSSL keine Workarounds an. Die Schwachstelle wurde am 17. August von Laurent Gaffie von Secorizon entdeckt, die Behebung wurde von Ryan Hooper entwickelt – der Commit ist auf GitHub verfügbar. Trotz des fehlenden Nachweises einer Ausnutzung macht die Kombination aus Speicherleck und der Möglichkeit eines entfernten Denial of Service über einen Netzwerkvektor ohne Authentifizierung ein zeitnahes Update für alle, die DTLS auf Basis von OpenSSL einsetzen, zur vorrangigen Aufgabe.