Administratorzy Java powinni dopasować wersję do komunikatu właściwego dostawcy, a przed zmianą truststore wykonać jego kopię zapasową. Alert Oracle z 21 października 2026 r. dotyczy CVE-2026-91403 w JSSE i przypisuje luce ocenę 9,1 w skali CVSS 3.1. Gdy aktualizacji Oracle nie da się od razu zainstalować, firma opisuje też dwie działania dotyczące certyfikatów: ich usunięcie z magazynu zaufanych certyfikatów albo włączenie sprawdzania unieważnienia w aplikacjach TLS.
Czego dotyczy CVE-2026-91403
Oracle wskazuje komponent JSSE, czyli biblioteki Java używane do komunikacji sieciowej. W macierzy ryzyka opisuje atak przez sieć, niską złożoność ataku, brak wymaganych uprawnień i interakcji użytkownika oraz duży wpływ na poufność i integralność danych. Wpływ na dostępność określa jako żaden. Ocena 9,1 w skali CVSS 3.1 podsumowuje te warunki i skutki.
Oracle opisuje działanie aktualizacji jako odrzucanie zaufania do dotkniętych problemem certyfikatów pośrednich powiązanych z eMudhra. Z kolei alert Oracle wymienia konkretne produkty i wersje objęte jego macierzą.
Dopasuj wersję do właściwego komunikatu
W macierzy Oracle wymienia następujące wydania:
- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5 i 27.0.1.
- Oracle GraalVM for JDK: 17.0.21 i 21.0.13.
- Oracle GraalVM Enterprise Edition: 21.3.20.
Oracle informuje, że poprawki z alertów bezpieczeństwa udostępnia dla wersji objętych Premier Support lub Extended Support. Wydań poza tymi okresami nie testuje pod kątem tego problemu, a wcześniejsze wersje również mogą być nim dotknięte.
OpenJDK opublikował osobny komunikat dla CVE-2026-91403 w kategorii security-libs/javax.net.ssl i zaleca aktualizację. Jego zestawienie obejmuje wersje 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 i wcześniejsze. To osobna informacja o zakresie OpenJDK, a nie zamiennik macierzy produktów Oracle. Właściwy numer wersji trzeba więc odczytać z komunikatu dotyczącego używanego produktu i dostawcy. Komunikat OpenJDK
Jak zastosować mitygację Oracle
Oracle zaleca najpierw wykonać kopię zapasową truststore, czyli magazynu zaufanych certyfikatów. Następnie można wybrać jedną z opisanych ścieżek. Instrukcja Oracle Java podaje osobną składnię dla Java 8 oraz JDK 11 i nowszych.
1. Wykonaj kopię zapasową
Przed zmianą magazynu zaufanych certyfikatów utwórz jego kopię. To pierwszy krok opisany przez Oracle.
2. Wybierz jedną z dwóch ścieżek
Usunięcie certyfikatów głównych. Oracle wskazuje aliasy emsigneccrootcag3 [jdk] dla emSign ECC Root CA - G3 oraz comodoaaaca [jdk] dla AAA Certificate Services. Dla JDK 11 i nowszych instrukcja podaje polecenia:
keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -cacerts -alias "comodoaaaca [jdk]"
W Java 8 należy zamiast -cacerts użyć -keystore [JDK_HOME]/jre/lib/security/cacerts:
keytool -delete -keystore [JDK_HOME]/jre/lib/security/cacerts -alias "emsigneccrootcag3 [jdk]"
keytool -delete -keystore [JDK_HOME]/jre/lib/security/cacerts -alias "comodoaaaca [jdk]"
Sprawdzanie unieważnienia certyfikatów TLS. Alternatywnie Oracle zaleca włączyć tę kontrolę dla aplikacji TLS za pomocą właściwości JVM:
-Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true
3. Uwzględnij pozostałe instalacje i magazyny
Wybraną zmianę trzeba powtórzyć w każdej dotkniętej problemem instalacji Java oraz w niestandardowych truststore’ach używanych przez aplikacje. Warto sprawdzić osobno składnię dla Java 8 i JDK 11+, zamiast stosować te same polecenia do obu wersji.
Kontrola podpisanego pliku JAR
Do weryfikacji podpisanego pliku JAR z kontrolą unieważnienia Oracle podaje dla JDK 17 i nowszych polecenie:
jarsigner -verify -revcheck -strict [SIGNED_JAR]
