Java-Runtimes prüfen TLS-Zertifikate gegen einen mitgelieferten Vertrauensspeicher — und genau dieser Speicher war das Problem. CVE-2026-91403 beschreibt eine Schwäche in der JSSE-Komponente von Oracle Java SE, Oracle GraalVM und OpenJDK: Zwischenzertifikate der Zertifizierungsstelle eMudhra, deren private Schlüssel als kryptografisch schwach gelten und kompromittiert wurden, wurden von Java weiterhin als vertrauenswürdig behandelt. Das BSI führt die Lücke mit Risiko „kritisch", Oracle hat am 21. Oktober 2026 ein außerplanmäßiges Sicherheitsupdate veröffentlicht.
CVE-2026-91403: Wie der Angriff auf Java-TLS funktioniert
Der Vertrauensspeicher ist die Instanz, die entscheidet, ob eine TLS-Verbindung als sicher gilt. Enthält er eine Root-CA, die Zwischenzertifikate mit schwachen Schlüsseln signiert hat, erbt jedes darunter ausgestellte Zertifikat diese Vertrauensstellung — unabhängig davon, wie solide der eigentliche Server konfiguriert ist.
Konkret heißt das: Ein Man-in-the-Middle-Angreifer kann Zertifikate für beliebige Hostnamen ausstellen, die ein Java-TLS-Client als gültig akzeptiert. Die Anwendung verbindet sich dann mit einer bösartigen Gegenstelle, ohne zu warnen; TLS- und Anwendungsdaten lassen sich mitlesen oder verändern. Das BSI beschreibt in seiner Meldung genau dieses Szenario: Zertifikate für fremde Hostnamen, Identitätsübernahme gegenüber Websites, Manipulation des Datenstroms.
Red Hat ordnet die Wirkung mit „Bypass Protection Mechanism; Gain Privileges or Assume Identity" ein — die Lücke hebelt also nicht eine einzelne Signatur aus, sondern die Schutzmechanik, die TLS überhaupt erst absichert. Eine Auswirkung auf die Verfügbarkeit ist nicht Teil der Bewertung.
Welche Java-Versionen betroffen sind
Das BSI formuliert die Grenze als Untergrenze: verwundbar sind alle Stände unterhalb von 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 und 27.0.1. Oracle nennt in seiner Beschreibung dieselben Releases als die Stände, in denen der Fix enthalten ist, ergänzend GraalVM for JDK in den Versionen 17.0.21 und 21.0.13 sowie GraalVM Enterprise Edition 21.3.20.
Praktisch relevant ist das vor allem dort, wo Java nicht auf dem Entwickler-Notebook liegt, sondern in Anwendungsservern, Build-Pipelines, CI-Runnern und eingebetteten Geräten. Diese Installationen werden selten über den Paketmanager gepflegt, und ein Truststore-Update erreicht sie nur, wenn jemand die Runtime selbst anfasst.
Zwei Scores für dieselbe Lücke
Oracle und cve.org bewerten CVE-2026-91403 mit einem CVSS-3.1-Base-Score von 9.1, Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — also angreifbar aus dem Netz, ohne Vorbedingungen, ohne Interaktion eines Nutzers, mit hoher Auswirkung auf Vertraulichkeit und Integrität. Red Hat kommt produktspezifisch auf 6.8 und begründet den Unterschied mit AC:H und UI:R, also erschwerten Angriffsbedingungen und notwendiger Nutzerinteraktion. Eine inhaltliche Herleitung für diese Abweichung liefert Red Hat nicht. Ein NVD-Score war in der Red-Hat-Tabelle zum Stand 22. Oktober 2026 mit „N/A" geführt.
Für Betreiber ist der Disput zweitrangig: Beide Bewertungen liegen über dem, was man ignorieren könnte, und die Lücke betrifft die Vertrauenskette selbst — nicht eine Anwendung, die man einfach abschalten kann.
Drei Wege zum Fix — je nach Installationsart
Oracles Notfall-Update entfernt das betroffene Root-Zertifikat nicht. Der Upstream-Fix blockiert die problematischen Zwischenzertifikate im Truststore, die Vertrauenskette bleibt also strukturell erhalten, nur der kompromittierte Pfad fällt weg.
Wie der Fix ankommt, hängt von der Bauform ab. Nicht-portable OpenJDK-RPMs unter RHEL nutzen die ca-certificates-Pakete als Standard-Truststore und erhalten die Korrektur über dieses Paket, referenziert als CVE-2026-114406. Portable OpenJDK-Builds für Linux und Windows bringen einen eigenen Zertifikatsspeicher mit und müssen separat aktualisiert werden — sie profitieren nicht von einem ca-certificates-Update.
Für Umgebungen, in denen kein Update eingespielt werden kann, kursiert eine manuelle Variante: Truststore sichern, dann emsigneccrootcag3 [jdk] (emSign ECC Root CA – G3) und comodoaaaca [jdk] (AAA Certificate Services) per keytool -delete -cacerts entfernen, unter Java 8 stattdessen über -keystore $JDK_HOME/jre/lib/security/cacerts. Zusätzlich lässt sich die Sperrprüfung über -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true sowie jarsigner -verify -revcheck -strict aktivieren.
Diese Anleitung weicht methodisch vom Upstream-Ansatz ab: Sie löscht Root-Zertifikate, statt Zwischenzertifikate zu blockieren. Ob beide Wege gleichwertig sind, ist nicht belegt — und das Entfernen eines breit genutzten Roots kann andere Zertifikatsketten mitreißen. Wer den Eingriff plant, sollte ihn zuerst in einer Testumgebung gegen die eigenen Zielsysteme prüfen.
Was Betreiber jetzt tun sollten
Die BSI-Empfehlung ist unspektakulär und richtig: zeitnah die vom Hersteller bereitgestellten Sicherheitsupdates installieren. Der Aufwand liegt weniger im Patch als im Finden der Installationen — wer ein Runtime-Inventar führt, hat es jetzt leichter.
Konkret: Java SE und GraalVM auf mindestens 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 oder 27.0.1 heben, bei GraalVM for JDK auf 17.0.21 oder 21.0.13, bei GraalVM Enterprise Edition auf 21.3.20. RHEL-Systeme mit nicht-portablen OpenJDK-RPMs brauchen das aktuelle ca-certificates-Paket, portable Builds und Container-Images ein eigenes Update. Custom-Truststores und mitgelieferte Zertifikatsspeicher in Anwendungen sind separat zu prüfen.
Eine bestätigte Ausnutzung ist bislang nicht gemeldet; ein öffentlicher Proof of Concept lag Stand 22. Oktober 2026 nicht vor. Das ist eine Momentaufnahme und kein Freibrief: Eine Lücke, die sich laut CVSS ohne Nutzerinteraktion ausnutzen lässt, wird selten lange ungenutzt bleiben.