CVE-2026-91403: Java ufała skompromitowanym certyfikatom eMudhra

Białe koperty zapieczętowane czerwonym lakiem na drewnianym stole

Dlaczego zaufany certyfikat pośredni to furtka do każdej domeny

Java przy każdym połączeniu TLS sprawdza, czy certyfikat serwera prowadzi łańcuchem do urzędu certyfikacji, któremu ufa. Wśród zaufanych znalazło się osiem certyfikatów pośrednich eMudhra, których klucze prywatne wygenerowano z błędem. Według ogłoszenia OpenJDK da się je odtworzyć w ułamku sekundy. Kto ma taki klucz, może wystawić certyfikat dla dowolnej domeny, a aplikacja Java przyjmie go bez żadnego ostrzeżenia.

W praktyce oznacza to, że atakujący, który może przechwycić ruch między Waszą aplikacją a usługą zewnętrzną, podszyje się pod dowolny serwer HTTPS. Aplikacja wyśle mu klucze API, tokeny i dane, a jego odpowiedzi uzna za prawdziwe. Dotyczy to wywołań zewnętrznych API, integracji z systemami partnerów i sprawdzania aktualizacji.

Oracle wydał alert poza cyklem i ocenia lukę w komponencie JSSE na 9.1 w CVSS 3.1. Red Hat daje 6.8, bo bez pozycji man-in-the-middle nie da się jej wykorzystać. Ta różnica dobrze pokazuje, że o pilności decyduje to, przez jaką sieć idzie Wasz ruch. Przeglądarki zablokowały te certyfikaty w dniach 17–20 października, ale JDK ma własny magazyn certyfikatów i potrzebuje osobnej poprawki. Planowa aktualizacja Java (CPU) z 20 października problemu nie usuwa: wydane wtedy wersje są na liście podatnych. eMudhra i badacze nie znaleźli śladów nadużycia kluczy, a CVE nie ma w katalogu CISA KEV (stan na 22 października 2026 r.).

Kto jest naprawdę narażony

Najbardziej narażone są aplikacje Java, które same łączą się przez TLS jako klient, gdy ruch idzie przez sieć, na którą atakujący może mieć wpływ: publiczny internet, sieci współdzielone, Wi-Fi, z którego korzystają laptopy z narzędziami w Javie, albo sieć firmowa, w której ktoś już się zadomowił. Mniej narażone są serwery, które tylko przyjmują połączenia od przeglądarek, bo certyfikat sprawdza wtedy przeglądarka. Podobnie systemy, które rozmawiają wyłącznie w zamkniętej sieci wewnętrznej.

Podatne wersje

Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1. Oracle zaznacza, że starsze wersje są najpewniej również podatne.
Oracle GraalVM for JDK 17.0.21 i 21.0.13 oraz GraalVM Enterprise Edition 21.3.20.
OpenJDK w samodzielnych instalacjach (archiwum, instalator, JDK dołączone do aplikacji lub obrazu kontenera): 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 i wcześniejsze.
OpenJDK z pakietów systemowych (m.in. Debian, Ubuntu, Red Hat Enterprise Linux, Fedora, Oracle Linux) korzysta z systemowego magazynu certyfikatów, więc wystarczy aktualizacja pakietu ca-certificates. Wersje z FreeBSD i Homebrew trzeba zaktualizować bezpośrednio.

Numer poprawionej kompilacji dla Waszej linii Java podaje dokument Patch Availability, do którego odsyła alert Oracle. Sprawdźcie go przed aktualizacją.

Gdzie Java chowa się poza serwerem aplikacji

Jedno java -version na głównym serwerze nie wystarczy. Java często siedzi w miejscach, o których nikt nie pamięta.

Serwery i stacje robocze: sprawdźcie java -version i ustalcie, skąd pochodzi Java. Pakiet systemowy pokaże dpkg -l | grep openjdk lub rpm -qa | grep openjdk, a oczekującą aktualizację certyfikatów apt list --upgradable | grep ca-certificates lub dnf check-update ca-certificates.
Serwery aplikacji i oprogramowanie dostawców z wbudowanym środowiskiem Java. Każda kopia ma własny magazyn certyfikatów. Znajdzie je find / -path '*/bin/java' -type f 2>/dev/null. Przy produktach dostawców sprawdźcie, czy jest aktualizacja.
Obrazy Docker: linia FROM w plikach Dockerfile. Obraz z dołączonym JDK nie zaktualizuje się sam: trzeba go przebudować.
Agenty CI i serwery buildów: wersja JDK w pipeline. Build pobiera zależności przez TLS, więc agent też jest klientem TLS.

Polecenia mvn dependency:tree i gradle dependencies tego problemu nie pokażą, bo dotyczy samego JDK.

Dziś i w najbliższym oknie serwisowym

Dziś

Na systemach z OpenJDK z dystrybucji zaktualizujcie ca-certificates (apt upgrade ca-certificates lub dnf upgrade ca-certificates) i zrestartujcie usługi Java, żeby wczytały nowy magazyn.
Dla aplikacji z samodzielnym JDK, które łączą się z usługami w internecie i nie mogą jeszcze dostać aktualizacji, OpenJDK podaje dwa obejścia. Pierwsze to podmiana pliku $JDK_HOME/lib/security/blocked.certs na nową wersję (w JDK 8 plik nazywa się blacklisted.certs). Drugie to włączenie sprawdzania unieważnień parametrami -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true. Drugie obejście zmienia zachowanie każdego połączenia TLS, więc przetestujcie je przed wdrożeniem na produkcji.
Przy wątpliwościach uruchomcie aplikację z opcją -Djava.security.debug=certpath i szukajcie w łańcuchach certyfikatów nazw emSign albo eMudhra.

W najbliższym oknie serwisowym

Zaktualizujcie samodzielne instalacje Oracle JDK, GraalVM i OpenJDK do poprawionych kompilacji, przebudujcie obrazy kontenerów i wdrożcie aktualizacje od dostawców oprogramowania.
W tym samym restarcie wdrożcie październikowe CPU: zawiera 55 poprawek dla Java SE, z najwyższą oceną 7.5.
Podpisane pliki JAR (JDK 17 i nowsze) możecie zweryfikować z kontrolą unieważnień: jarsigner -verify -revcheck -strict plik.jar.

Śladów nadużycia kluczy nie ma, więc szukanie włamania nie jest potrzebne.

Spis JDK to podstawa szybkiej reakcji

Przeglądarki odcięły te certyfikaty w kilka dni, a w Javie każda kopia JDK wymaga osobnej poprawki. Firma, która ma spis wszystkich instalacji Java, łącznie z tymi dołączonymi do oprogramowania dostawców i obrazów kontenerów, załatwi taką sprawę w jedno popołudnie. Warto zapisać przy każdej: wersję, źródło (pakiet systemowy, archiwum, obraz, produkt dostawcy) i osobę odpowiedzialną. Tam, gdzie się da, wybierajcie OpenJDK z pakietów dystrybucji, bo wtedy magazyn certyfikatów aktualizuje się razem z systemem.