OpenSSL und WolfSSL schließen schwere TLS-Lücken
Die Entwickler zweier weit verbreiteter Open-Source-Kryptobibliotheken, OpenSSL und WolfSSL, haben jeweils Korrekturen für rund ein Dutzend Sicherheitsprobleme veröffentlicht. In beiden Paketen stecken Lücken mit hohem Schweregrad. Bei WolfSSL können Angreifer mit drei davon die Authentifizierung der Gegenstelle umgehen.
OpenSSL stopft Speicherleck in DTLS
OpenSSL hat 14 Schwachstellen behoben. Nur eine davon gilt als schwerwiegend. Sie wird als CVE-2026-84782 geführt und betrifft Anwendungen, die Datagram TLS (DTLS) nutzen. DTLS ist eine TLS-Variante für verbindungslosen Datenverkehr und findet sich häufig in VPNs, VoIP-Systemen und IoT-Geräten.
Der Fehler tritt beim DTLS-Handshake auf. Überträgt OpenSSL eine Nachricht erneut, während das Senden einer anderen Nachricht ins Stocken geraten ist, können Reste von Heap-Daten im Klartext an die Gegenseite gehen. Eine entfernte Gegenstelle kann so Bruchstücke des Heap-Speichers abgreifen. Trifft der Lesezugriff auf nicht zugeordneten Speicher, stürzt die Anwendung ab. Das Ergebnis ist ein Denial-of-Service (DoS).
Die Lücke hat einen CVSS-Wert von 8,2. Sie lässt sich über das Netzwerk ausnutzen, ohne Authentifizierung und ohne Zutun des Nutzers.
Die neuen Versionen beheben außerdem ein Problem mittlerer Schwere, CVE-2026-84783. Eine entfernte, nicht authentifizierte Gegenstelle kann damit einen Multithread-TLS-Client zum Absturz bringen, was ebenfalls zu einem DoS führt.
Die übrigen OpenSSL-Fehler sind als gering eingestuft. Die meisten verursachen DoS-Zustände durch übermäßigen Speicher- oder CPU-Verbrauch, Prozessabstürze oder den Abbruch von DTLS-1.2-Verbindungen. Zwei weitere Arten von Problemen fallen auf. Einige könnten es Angreifern erlauben, QUIC-Server für DDoS-Verstärkungsangriffe zu missbrauchen. Bei anderen geht es um Timing-Seitenkanäle, über die Informationen durchsickern könnten, die bei der Rekonstruktion privater Schlüssel helfen.
WolfSSL 5.9.4 schließt Authentifizierungslücken
WolfSSL hat am 25. September Version 5.9.4 veröffentlicht. Neben neuen Funktionen behebt die Version 11 Schwachstellen, drei davon mit hohem Schweregrad. Jede der drei kann es einem Angreifer in bestimmten Konfigurationen ermöglichen, die Authentifizierung der Gegenstelle zu umgehen.
CVE-2026-93302 entsteht, weil WolfSSL den öffentlichen Schlüssel nicht prüft, wenn es ein Zertifikat mit einem vertrauenswürdigen Zertifikat der Gegenstelle abgleicht. Ein bösartiger Server, der weiß, welchen Zertifizierungsstellen (CAs) ein Client vertraut, kann einen gefälschten Klon einer dieser CAs vorlegen und so die Authentifizierung überwinden. Betroffen sind unter anderem Builds für die Integration mit Nginx, HAProxy, Stunnel, Apache httpd und weiteren Anwendungen.
CVE-2026-89102 setzt an anderer Stelle an. Ein Angreifer, der ein beliebiges Zertifikat samt privatem Schlüssel besitzt, das auf eine vom Client als vertrauenswürdig eingestufte CA zurückgeht, kann Zertifikate für beliebige Identitäten fälschen.
CVE-2026-89136 betrifft Clients, bei denen die Unterstützung für Raw Public Keys (RPK) aktiviert ist. Ein bösartiger Server kann die Authentifizierung umgehen, indem er einen RPK-Zertifikatstyp wählt, den der Client gar nicht angefordert hat.
Vier Fehler mittlerer Schwere hängen mit Mängeln bei der Zertifikatsprüfung und einem Fehler in der Handshake-Reihenfolge zusammen. Ein Angreifer könnte damit Namensbeschränkungen aushebeln oder eine ungeprüfte CA in den gemeinsam genutzten Zertifikatsmanager einschleusen. Über den Handshake-Fehler könnte ein Angreifer anstelle des legitimen Servers einen TLS-1.2- oder DTLS-1.2-Handshake abschließen und Daten senden, die der Client als echt akzeptiert.
Die vier Probleme geringer Schwere könnten Folgendes verursachen:
- einen Use-after-free beim Beenden einer Verbindung
- übersprungene CRL-Sperrprüfungen
- die Annahme von Zertifikaten mit ungültigen Signaturen
- das Vortäuschen eines Servers
Die meisten davon setzen bestimmte Konfigurationen oder die Nutzung veralteter APIs voraus.
Warum das wichtig ist
Die beiden Bibliotheken sind auf unterschiedliche Weise angreifbar. Die schwere OpenSSL-Lücke lässt Speicher durchsickern und bringt Dienste zum Absturz. Die WolfSSL-Lücken zielen auf das Vertrauensmodell selbst und lassen einen bösartigen Server als legitim durchgehen. Für eine TLS-Bibliothek sind Authentifizierungsumgehungen wohl die ernstere Kategorie, denn sie untergraben genau die Garantie, auf die sich Nutzer bei der Bibliothek verlassen.
Der DTLS-Aspekt verdient Beachtung. DTLS ist in VPNs und IoT-Geräten verbreitet, und diese Produkte werden oft nur schleppend gepatcht. Geräte am Netzwerkrand ziehen weiterhin Angreifer an, wie die jüngsten Angriffe auf VPN-Appliances zeigen. WolfSSL ist in Embedded-Produkten beliebt, daher kann es dauern, bis die Korrekturen über die Firmware der Hersteller bei den Endnutzern ankommen.
Die Timing-Seitenkanal-Fehler in OpenSSL sind als gering eingestuft. Dennoch reihen sie sich in eine stetige Folge von Forschungsarbeiten zu Datenlecks über Timing und Hardwareverhalten ein, etwa die kürzlich entdeckte Spectre-v2-Variante.
Einiges lohnt sich im Blick zu behalten. Zum einen, ob nachgelagerte Hersteller, die diese Bibliotheken mitliefern, eigene Sicherheitshinweise herausgeben. Zum anderen, ob Proof-of-Concept-Code für die WolfSSL-Authentifizierungsumgehungen auftaucht. Teams, die die Integrationen für Nginx, HAProxy, Stunnel oder Apache httpd nutzen, sollten ihre Builds zuerst prüfen.