Die schwerwiegendste OpenSSL-Lücke, CVE-2026-84782, wird während des DTLS-Handshakes ausgelöst: Sendet OpenSSL eine Nachricht erneut, während der Versand einer anderen ins Stocken geraten ist, können Reste von Heap-Daten im Klartext an die Gegenstelle übertragen werden. Greift der Lesevorgang auf nicht zugeordneten Speicher zu, stürzt die Anwendung ab — ein klassischer Denial-of-Service.
Daneben behebt OpenSSL mit CVE-2026-84783 eine Schwachstelle mittleren Schweregrads, über die eine entfernte, nicht authentifizierte Gegenstelle einen mehrfädigen TLS-Client zum Absturz bringen kann. Die übrigen Fehler sind als niedrig eingestuft. Sie führen überwiegend ebenfalls zu Dienstausfällen, etwa durch übermäßigen Speicher- oder CPU-Verbrauch, Prozessabstürze oder den Abbruch von DTLS-1.2-Verbindungen. Zwei weitere Probleme erlauben es, QUIC-Server für DDoS-Verstärkung zu missbrauchen oder über Timing-Seitenkanäle Informationen zu sammeln, die zur Wiederherstellung privater Schlüssel führen können.
Bei WolfSSL liegt der Schwerpunkt auf fehlerhafter Zertifikatsprüfung. CVE-2026-93302 entsteht dadurch, dass WolfSSL beim Abgleich eines Zertifikats gegen ein vertrauenswürdiges Peer-Zertifikat den öffentlichen Schlüssel ignoriert. Ein bösartiger Server, der weiß, welchen Zertifizierungsstellen ein Client vertraut, kann einen gefälschten CA-Klon präsentieren und so die Authentifizierung umgehen. Betroffen sind unter anderem Builds, die für den Einsatz mit Nginx, HAProxy, Stunnel, Apache httpd und weiteren Anwendungen erstellt wurden.
CVE-2026-89102 erlaubt es einem Angreifer, der irgendein Zertifikat samt zugehörigem privaten Schlüssel besitzt, das sich auf eine vom Client als vertrauenswürdig eingestufte CA zurückführen lässt, Zertifikate für beliebige Identitäten zu fälschen. CVE-2026-89136 wiederum lässt einen bösartigen Server die Authentifizierung bei Clients mit aktivierter Unterstützung für Raw Public Keys aushebeln, indem er einen RPK-Zertifikatstyp wählt, den der Client nie angefordert hat.
Vier weitere WolfSSL-Fehler mittleren Schweregrads betreffen Mängel bei der Zertifikatsvalidierung sowie einen Reihenfolgefehler im Handshake. Angreifer könnten damit Namensbeschränkungen umgehen, eine ungeprüfte CA im gemeinsam genutzten Zertifikatsmanager platzieren oder anstelle des legitimen Servers einen TLS-1.2- beziehungsweise DTLS-1.2-Handshake abschließen und anschließend Daten senden, die der Client als authentisch akzeptiert.
Die vier als niedrig eingestuften Fehler können zu einem Use-after-free beim Verbindungsabbau führen, dazu, dass CRL-Sperrprüfungen übersprungen werden, dass Zertifikate mit ungültiger Signatur akzeptiert werden, oder zur Nachahmung eines Servers. Die meisten dieser Fälle setzen spezifische Konfigurationen oder die Nutzung veralteter Programmierschnittstellen voraus.