Zurück

2026/10/30

Browser waren nach Stunden geschützt. Und Java im Unternehmen? Wie LOGIQ auf den eMudhra-Zertifikatsvorfall reagiert hat

Browser sperrten die kompromittierten eMudhra-Zwischenzertifikate in Stunden, doch jedes JDK hat einen eigenen Truststore. Was Azul, BellSoft und LOGIQ taten.

Das Wichtigste in Kürze

  • Am 17. Oktober 2026 erhielt Mozilla eine Meldung, dass die privaten Schlüssel von acht Zwischen-CA-Zertifikaten von eMudhra kompromittiert waren. Browser sperrten sie innerhalb von Stunden bis Tagen. Laut eMudhra liegen keine Hinweise darauf vor, dass die Schlüssel ausgenutzt wurden.
  • Java übernimmt nicht die Vertrauensentscheidungen des Browsers oder des Betriebssystems. Jedes JDK – und jedes Container-Image oder jede Anwendung, die eines mitbringt – hat einen eigenen Truststore. Jeder davon muss separat aktualisiert werden.
  • Azul hat zwei außerplanmäßige Zulu-Updates veröffentlicht, am 21. und am 24. Oktober. Das zweite gibt es, weil die erste Korrektur nicht ausreichte; der Workaround vom 21. Oktober genügt für sich allein daher nicht mehr.
  • BellSoft nennt korrigierte Liberica-Builds für Java 8, 11, 17, 21, 25 und 27. LOGIQ hat diese Builds über unseren BellSoft-Supportkanal bezogen und unseren Kunden bereitgestellt.
  • Was zu tun ist: Alle eingesetzten Java-Laufzeitumgebungen ermitteln, genauen Hersteller und Build prüfen, auf den korrigierten Build des jeweiligen Herstellers umstellen, die TLS-Verbindungen testen und weiter auf außerplanmäßige Releases achten.

Was ist passiert?

Am Samstag, dem 17. Oktober 2026, um 20:06 UTC erhielt Mozilla eine Meldung, dass die privaten Schlüssel von acht Zwischenzertifikaten von eMudhra kompromittiert waren. Mozilla sperrte die acht Zertifikate in Firefox über OneCRL, seine zentrale Sperrliste, und das Update hatte Nutzer mit Standardeinstellungen um 22:59 UTC erreicht – weniger als drei Stunden später. Mozilla machte den Vorfall am 20. Oktober öffentlich. Zudem veröffentlichte Mozilla Firefox-Point-Releases für Nutzer, deren Einstellungen das OneCRL-Update blockierten, und entfernte das Root-Zertifikat, das die Zwischenzertifikate signiert hatte, aus dem NSS-Truststore.

Das Risiko besteht in gefälschten Zertifikaten. Wer einen dieser Schlüssel besitzt, könnte ein HTTPS-Zertifikat für eine Website ausstellen, die er nicht kontrolliert. Könnte er sich zusätzlich zwischen einen Client und diese Website schalten, wäre es ihm möglich, sich als diese Website auszugeben und den Datenverkehr mitzulesen oder zu verändern.

Bislang gibt es keine Hinweise darauf, dass dies geschehen ist. In seiner Stellungnahme zum Vorfall erklärt eMudhra, die acht Zwischenzertifikate seien am 18. Oktober widerrufen worden, keines davon habe End-Entity-Zertifikate ausgestellt, und man habe „keine Kenntnis von Hinweisen darauf, dass die schwachen Schlüssel vor der Offenlegung des Problems von irgendjemandem rekonstruiert oder ausgenutzt wurden“. Als Ursache nennt eMudhra schwache Schlüssel, die bei einer Key Ceremony im Jahr 2025 erzeugt wurden. Die genaue Grundursache sei noch nicht bestätigt, die Untersuchung dauere an. Die Root-Programme der Browser haben der eMudhra-Root oberhalb dieser Zwischenzertifikate vorsorglich das Vertrauen entzogen.

In diesem Artikel geht es also darum, ein Zeitfenster der Angreifbarkeit zu schließen, nicht um einen bestätigten Angriff.

Warum Java eine eigene Korrektur braucht

Browser und Betriebssysteme verfügen über automatische Mechanismen, um einer Zertifizierungsstelle das Vertrauen zu entziehen, und haben diese schnell genutzt. Laut Azuls Darstellung des Vorfalls sperrte Chrome die Zertifikate noch am selben Tag, Apple am 19. Oktober und Microsoft am 20. Oktober.

Java übernimmt nichts davon. Ein JDK entscheidet anhand eigener Dateien, welchen Zertifikaten es vertraut:

  • Ein eigener Truststore. Jedes JDK bringt seine eigene cacerts-Datei mit. Ein Update des Zertifikatsbundles des Betriebssystems oder ein Browser-Neustart ändert daran nichts.
  • Standardmäßig keine Sperrprüfung. Wie es in der Dokumentation von Azul heißt, vertraut Java den Root-Zertifikaten, auf die diese Zwischenzertifikate zurückgehen, und „prüft standardmäßig keinen Widerruf“. Dass eMudhra die Zwischenzertifikate widerrufen hat, schützt einen Java-Client für sich genommen also nicht.
  • Viele Kopien. Auf einem Server können das System-JDK, ein in eine Anwendung eingebettetes JDK, eine jlink-Laufzeitumgebung und mehrere Container-Images laufen – jeweils mit einer eigenen Kopie des Truststores. Jede Kopie bleibt angreifbar, bis sie aktualisiert oder neu gebaut wird.

Ein Java-Dienst, der ausgehende TLS-Verbindungen aufbaut, kann also weiterhin ein gefälschtes Zertifikat akzeptieren, wenn längst jeder Browser im Haus geschützt ist. Um genau diese Lücke geht es in diesem Artikel.

Zwei Notfall-Updates von Azul

Azul hat nach seinem quartalsweisen Oktober-Release zwei außerplanmäßige Updates für Azul Zulu veröffentlicht:

  • 21. Oktober: Das erste außerplanmäßige Update nimmt die acht kompromittierten Zwischenzertifikate in die Sperrliste des JDK auf (blocked.certs ab JDK 11, blacklisted.certs in älteren Versionen). Es deckt Zulu 27, 25, 21, 17, 11, 8, 7 und 6 ab. Azuls CVE-Liste führt es als CVE-2026-91403. Für Laufzeitumgebungen, die sich nicht sofort aktualisieren ließen, veröffentlichte Azul außerdem einen manuellen Workaround, der die Sperrlistendatei ersetzt.
  • 24. Oktober: Azul stellte fest, dass die Sperrliste das Problem nicht vollständig behob. Das zweite außerplanmäßige Update behebt CVE-2026-114820 (JSSE, Base Score 9.1), indem bestimmte CA-Zertifikate ganz aus cacerts entfernt werden. Zum Zeitpunkt der Veröffentlichung sind diese Builds für Azuls reine Security-Linie (CPU) verfügbar, sowohl auf Basis des CPU vom Oktober 2026 (zum Beispiel Zulu 21.53.114, 17.69.114, 11.91.114 und 8.97.0.112) als auch auf Basis des CPU vom Juli 2026. Laut Azul werden PSU-Builds „voraussichtlich“ in einem separaten Update folgen.

Das Update vom 24. Oktober ändert die Empfehlung. Azuls Workaround-Seite warnt inzwischen, dass dieser „das Problem nicht mehr vollständig behebt“, und Azul fordert alle Kunden auf, auf das neueste Release zu aktualisieren. Wer das Update vom 21. Oktober oder den Workaround eingespielt hat, braucht trotzdem noch den Build vom 24. Oktober. In einem eigenen Beitrag schreibt Azul, dass von der Entscheidung für einen Respin bis zur Auslieferung der Security-only-Builds an Kunden etwa 12 Stunden vergingen.

Was BellSoft für Liberica JDK bereitgestellt hat

BellSoft veröffentlichte am 21. Oktober sein reguläres Liberica-JDK-Release vom Oktober 2026. Dieses Quartalsrelease nennt 52 behobene CVEs und enthält CPU-Builds für Java 6 und 7 (6u521 und 7u521). Die Release Notes gehen nicht auf das eMudhra-Problem ein.

BellSoft behandelt eMudhra in einem separaten Leitfaden, „Distrusting compromised eMudhra intermediates in Java“ (zuletzt aktualisiert am 27. Oktober). Darin sind als korrigierte Builds Liberica JDK 8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5 und 27.0.1.0.3+5 aufgeführt. Für Systeme, die noch nicht aktualisiert werden können, beschreibt der Leitfaden eine vorübergehende Gegenmaßnahme: die betroffenen Roots aus dem Truststore entfernen. Er warnt, dass dies legitime Zertifikatsketten unterbrechen kann und vorher getestet werden sollte.

Beim Vergleich der Hersteller sind zwei Punkte wichtig:

  • Die CVE-Listen sind nicht identisch. Azul und BellSoft veröffentlichen jeweils eine eigene CVE-Liste für den Oktober-Zyklus, und Anzahl und Hinweise unterscheiden sich. Die beiden oben genannten CVE-IDs von Azul stammen aus Azuls Unterlagen; der Leitfaden von BellSoft nennt sie nicht. Prüfen Sie die Release Notes Ihres eigenen Herstellers auf die genauen Korrekturen in Ihrem Build, und gehen Sie nicht davon aus, dass die Liste eines Herstellers auch für das JDK eines anderen gilt.
  • Java 6 und 7 stehen nicht auf BellSofts eMudhra-Liste. Die neuesten Java-6- und Java-7-Builds von BellSoft sind verfügbar, doch die Liste der korrigierten Builds im eMudhra-Leitfaden beginnt erst bei Java 8. Wenn Sie Liberica 6 oder 7 einsetzen, klären Sie, ob Ihr Build die Änderung am Truststore enthält, bevor Sie sich darauf verlassen, oder wenden Sie die Gegenmaßnahme des Herstellers an. Azul führt Builds vom 24. Oktober für Zulu 6 und 7.

Wie LOGIQ reagiert hat

Wir vertreiben Java-Builds von BellSoft und Azul an unsere Kunden und unterstützen sie bei der Migration weg von älteren Oracle-JDK-Versionen. Im Folgenden beschreiben wir, was wir unternommen haben, jeweils mit dem Stand zum Zeitpunkt der Veröffentlichung (29. Oktober).

Erledigt

  • 21.–22. Oktober: Herstellermitteilungen geprüft. Wir haben Azuls außerplanmäßige Mitteilung vom 21. Oktober und BellSofts Release-Mitteilung für Oktober 2026 erhalten und geprüft. Noch am selben Tag haben wir für beide Hersteller Download- und Repository-Aufgaben angelegt. Die beiden Releases haben wir getrennt behandelt und nicht angenommen, dass BellSofts Quartalsrelease dieselbe eMudhra-Korrektur enthält wie das von Azul.
  • 23. Oktober: Liberica-Quartalsbuilds bereitgestellt. Wir haben die Liberica-JDK-Builds vom Oktober 2026 aus BellSofts Supportportal heruntergeladen und in das Repository aufgenommen, aus dem unsere Kunden herunterladen.
  • 24.–25. Oktober: zweites Azul-Update nachverfolgt. Wir haben Azuls Mitteilung vom 24. Oktober aufgegriffen, einschließlich der Empfehlung, auch dann zu aktualisieren, wenn der Build vom 21. Oktober bereits installiert ist.
  • 27.–28. Oktober: korrigierte Liberica-Builds über BellSoft bezogen. Wir haben BellSoft im Rahmen unserer kommerziellen Supportbeziehung gebeten, die neuesten Builds in unserem Supportportal bereitzustellen. BellSoft hat sie am 28. Oktober hochgeladen, darunter die korrigierten Builds für Java 8, 11, 17, 21, 25 und 27 sowie die neuesten Java-6- und Java-7-Builds. Da einige Kunden weiterhin 32-Bit-Java 8 benötigen, haben wir BellSoft außerdem gebeten, die 32-Bit-Installer von 8u513+9 für Windows und Linux in unser Portal aufzunehmen. BellSoft hat sie noch am selben Tag ergänzt.
  • 28.–29. Oktober: Repository und Migrationszuordnungen aktualisiert. Wir haben diese Builds in unser Kunden-Download-Repository aufgenommen und unseren Leitfaden für die Migration von Oracle JDK zu Liberica so angepasst, dass er auf sie verweist; die Änderung wurde von einem zweiten Engineer geprüft.

Kunden mit Azul Zulu

Die Builds von Azul vom 21. und 24. Oktober erhalten Azul-Abonnenten direkt über Azul. Welcher Build der richtige ist, hängt von Ihrer Java-Version ab, davon, ob Sie die CPU- oder die PSU-Linie nutzen, und auf welcher Basis (Oktober oder Juli) Sie sich befinden. Prüfen Sie die Release Notes von Azul für Ihren genauen Build, oder fragen Sie uns – wir helfen Ihnen, ihn zu ermitteln.

Ältere Versionen: Java 6 und 7

Einige Kunden setzen noch Java 6 oder 7 ein, oft in Anwendungen, die sich nicht schnell migrieren lassen. Oracle stellt für diese Versionen keine öffentlichen Updates mehr bereit, ohne Optionen sind sie dennoch nicht. Wir unterstützen Kunden bei der Migration von alten Oracle-JDK-6- und -7-Builds auf die neuesten Liberica-JDK-6- und -7-Builds, und BellSofts Builds vom Oktober 2026 für beide Versionen stehen uns über BellSofts Supportportal zur Verfügung. Fehlt eine Korrektur oder ein Paket, das wir für diese Versionen benötigen, eskalieren wir dies über unseren kommerziellen Supportkanal an BellSoft. Für diesen Vorfall gilt der Hinweis oben: Vergewissern Sie sich, dass Ihr Java-6- oder Java-7-Build die eMudhra-Änderung am Truststore enthält, bevor Sie sich darauf verlassen.

Was Sie jetzt tun sollten

1. Alle Java-Laufzeitumgebungen ermitteln

Erfassen Sie jeden Ort, an dem Java läuft, nicht nur das System-JDK. Dazu gehören Applikationsserver, in Herstellerprodukte eingebettete Laufzeitumgebungen, jlink-Images, CI-Build-Agents und jedes Container-Image. Unter Linux findet dieser Befehl die Java-Binaries auf einem Host:

find / -xdev -type f -path "*/bin/java" 2>/dev/null

Bei Container-Images führen Sie die Prüfung innerhalb des Images aus, zum Beispiel mit docker run --rm --entrypoint java <image> -version.

2. Genauen Hersteller und Build prüfen

Die Hauptversion allein reicht nicht. Sie benötigen den Hersteller und die vollständige Build-Nummer, um sie mit der Liste der korrigierten Builds des Herstellers abzugleichen:

java -XshowSettings:properties -version 2>&1 | grep -E "java.vendor =|java.runtime.version|java.home"

Als schnellen Anhaltspunkt können Sie außerdem die eMudhra-Roots (emSign) im Truststore einer Laufzeitumgebung auflisten:

keytool -list -keystore "<java.home>/lib/security/cacerts" -storepass changeit | grep -i emsign

In unseren Tests mit den öffentlichen Container-Images von BellSoft listete ein älterer Liberica-Build 21.0.10 fünf emSign-Roots auf, die korrigierten Builds 21.0.13.0.3+5 und 8u513 dagegen keine. Ein leeres Ergebnis ist ein gutes Zeichen, aber kein Beweis. Die Azul-Korrektur vom 21. Oktober beispielsweise sperrte die Zwischenzertifikate, ohne Roots zu entfernen. Verlässlich ist die Prüfung der Build-Nummer. Unser früherer Artikel zur Prüfung von Java-Truststores beschreibt ausführlichere Prüfungen.

3. Den neuesten passenden Patch einspielen

  • Azul Zulu: Wechseln Sie auf den außerplanmäßigen Build vom 24. Oktober für Ihre Linie (CPU oder PSU, Basis Oktober oder Juli), auch wenn Sie den Build vom 21. Oktober installiert oder den Workaround angewendet haben. Wenn Sie PSU-Builds nutzen, achten Sie auf das nachfolgende PSU-Release von Azul.
  • Liberica JDK: Wechseln Sie auf die von BellSoft genannten korrigierten Builds (8u513+9, 11.0.33.0.3+7, 17.0.21.0.3+5, 21.0.13.0.3+5, 25.0.5.0.3+5, 27.0.1.0.3+5).
  • Andere Hersteller und eingebettete Laufzeitumgebungen: Prüfen Sie das Advisory des jeweiligen Herstellers. Ein JDK in einem Drittanbieterprodukt wird vom Hersteller dieses Produkts aktualisiert, nicht durch Ihre Betriebssystem-Updates.
  • Container: Bauen Sie die Images auf einem korrigierten Basis-Image neu und deployen Sie sie erneut. Einen laufenden Container zu patchen ändert das Image nicht.

4. TLS vor und während des Rollouts validieren

Das Entfernen von Roots aus einem Truststore kann legitime Verbindungen unterbrechen, etwa zu Websites, deren Zertifikate noch auf die entfernten eMudhra-Roots zurückgehen. Laut eMudhra werden betroffene Kundenzertifikate aus einer alternativen CA-Hierarchie neu ausgestellt. Testen Sie vor einem breiten Rollout die ausgehenden TLS-Verbindungen, auf die Ihre Anwendungen angewiesen sind, insbesondere zu Partnern oder Diensten, die eMudhra-Zertifikate verwenden könnten. Führen Sie den Rollout schrittweise durch, starten Sie die Java-Prozesse neu, damit sie den neuen Truststore laden, und prüfen Sie anschließend die laufende Version.

5. Auf außerplanmäßige Releases achten

Dieser Vorfall hat innerhalb von vier Tagen zwei Notfall-Releases für Java hervorgebracht, und weitere können folgen, etwa die PSU-Builds von Azul. Abonnieren Sie die Sicherheitsmitteilungen Ihrer Hersteller, prüfen Sie deren Release-Seiten direkt, statt sich nur auf E-Mails zu verlassen, und planen Sie Java-Updates auch außerhalb des Quartalsrhythmus ein.

Die Lehre daraus

Firefox-Nutzer waren innerhalb von Stunden geschützt, weil Browser eigene Truststores und einen automatischen Weg zu deren Aktualisierung haben. Java im Unternehmen hat viele Truststores, standardmäßig keine Sperrprüfung und Updates, die darauf warten, dass jemand sie installiert. Um diese Lücke zu schließen, braucht es eine genaue Bestandsaufnahme, exakte Build-Nummern, schnellen Zugriff auf Hersteller-Builds und einen Prozess, der nicht auf den nächsten Quartalspatch wartet. Wenn Sie Unterstützung beim Auffinden oder Aktualisieren der Java-Laufzeitumgebungen in Ihrer Umgebung benötigen, kontaktieren Sie LOGIQ.

Quellen