Java: aktualizacja z października 2026 i CVE-2026-91403, łatanie JVM

Java otrzymała dwa wydania bezpieczeństwa w ciągu dwóch dni. 20 października 2026 r. kwartalny Critical Patch Update Oracle usunął 55 podatności w Java SE, z których 49 można wykorzystać przez sieć bez logowania. 21 października Oracle wydał dodatkowo nadzwyczajny Security Alert dotyczący CVE-2026-91403, luki w implementacji TLS w Javie (JSSE) z oceną CVSS 9.1, a podatne wersje obejmują również te wydane dzień wcześniej. Japoński IPA ostrzegł 21 października, że wykorzystanie luki może spowodować awarię aplikacji lub pozwolić atakującemu przejąć kontrolę nad komputerem. Ten przewodnik pokazuje, na które wersje należy przejść, jak odszukać każde środowisko uruchomieniowe Javy, z którego Państwo korzystają, i jak sprawdzić, czy aktualizacja jest rzeczywiście używana.

Co zostało poprawione 20 października

Październikowy Critical Patch Update dotyczy Oracle Java SE 27, 26.0.2, 25.0.4.1, 21.0.12.1, 17.0.20.1, 11.0.32.1 i 8u503, a tym samym wszystkich starszych aktualizacji tych wersji. Żadna z 55 poprawek dla Javy nie ma oceny krytycznej, ale 49 luk można wykorzystać zdalnie bez uwierzytelnienia.

Java 26 nie otrzymała poprawki: jej aktualizacje zakończyły się we wrześniu 2026 r. Jeśli nadal Państwo z niej korzystają, należy przejść na wersję 27 lub na wydanie długoterminowe 25.

CVE-2026-91403: nowe wersje również są podatne

CVE-2026-91403 znajduje się w JSSE, części Javy obsługującej połączenia TLS. Według Oracle luka jest łatwa do wykorzystania, nie wymaga konta ani interakcji użytkownika i jest osiągalna przez sieć za pośrednictwem kilku protokołów, na przykład przez usługę WWW, która przekazuje dane do podatnych API. Udany atak pozwala odczytać i zmienić krytyczne dane (CVSS 9.1, AV:N/AC:L/PR:N/UI:N, wysoki wpływ na poufność i integralność).

Podatne są dokładnie wersje z 20 października: Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 i 27.0.1, a także GraalVM for JDK 17.0.21 i 21.0.13 oraz GraalVM Enterprise 21.3.20. Sama październikowa aktualizacja nie chroni więc przed tą luką.

Oracle udostępnia poprawkę dla Oracle JDK w dokumencie z łatką wskazanym w Security Alert, klientom z dostępem do My Oracle Support. W chwili pisania tego artykułu publiczne strony Oracle nie podają jeszcze nowych numerów wersji, a Oracle nie poinformował, czy luka jest już wykorzystywana. Projekt OpenJDK opublikował własny komunikat 21 października, więc kompilacje oparte na OpenJDK (Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat oraz pakiety dystrybucji Linuksa) otrzymują poprawki od tych dostawców. Należy sprawdzić stronę bezpieczeństwa swojego dostawcy i zainstalować pierwsze wydanie, które wymienia CVE-2026-91403. Zaktualizujemy ten artykuł, gdy publiczne numery wersji będą dostępne.

Krok 1: odszukanie każdego środowiska Javy

java -version pokazuje tylko Javę znajdującą się w PATH. Na serwerach często działa ich kilka: jedna dołączona do aplikacji, jedna w kontenerze, jedna zainstalowana przed laty w /opt.

W Linuksie to polecenie wyświetla każdy plik binarny Javy wraz z wersją:

sudo find / -xdev -type f -name java -perm -u+x 2>/dev/null | while read -r j; do echo "$j: $("$j" -version 2>&1 | head -n 1)"; done

To polecenie pokazuje, której Javy faktycznie używają działające procesy:

for p in $(pgrep -f java); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

W Dockerze należy sprawdzić wersję Javy w każdym uruchomionym kontenerze:

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" java -version 2>&1 | head -n 1)"; done

W Windows, w PowerShell:

Get-ChildItem 'C:\Program Files','C:\Program Files (x86)' -Recurse -Filter java.exe -ErrorAction SilentlyContinue | ForEach-Object { "$($_.FullName): $((& $_.FullName -version 2>&1 | Select-Object -First 1))" }

Proszę nie zapominać o oprogramowaniu, które dostarcza własną Javę, takim jak Jenkins, Elasticsearch, Keycloak, produkty Atlassian, pakiety Tomcat, agenty buildów i serwery gier.

Krok 2: aktualizacja

Ubuntu i Debian (pakiety OpenJDK):

sudo apt update && apt list --upgradable 2>/dev/null | grep -i jdk
sudo apt install --only-upgrade 'openjdk-*'

Red Hat, Rocky, AlmaLinux i Fedora:

sudo dnf upgrade 'java-*-openjdk*'

Oracle JDK: należy zainstalować październikowe wydanie dla swojej wersji ze strony pobierania Oracle, a następnie jak najszybciej łatkę na CVE-2026-91403 z My Oracle Support. Najpierw warto sprawdzić licencję: od wersji 21.0.13 aktualizacje Oracle JDK 21 nie są już objęte bezpłatnymi warunkami No-Fee Terms and Conditions, a użycie komercyjne może wymagać płatnej subskrypcji. W przypadku innych kompilacji OpenJDK, takich jak Temurin czy Corretto, należy zainstalować najnowsze wydanie od dostawcy.

Kontenery: aktualizacja na hoście nie zmienia kontenera. Należy pobrać zaktualizowany obraz bazowy, przebudować własne obrazy i wdrożyć je ponownie.

Krok 3: ponowne uruchomienie i weryfikacja

Java ładuje swój kod przy starcie, więc działająca usługa korzysta ze starej wersji aż do ponownego uruchomienia. Po aktualizacji pakietów w Linuksie to polecenie wyświetla procesy Javy, które nadal używają zastąpionych plików:

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'java.*(deleted)'

Należy ponownie uruchomić te usługi, jeszcze raz wykonać polecenia z kroku 1 i porównać wersje z powyższą tabelą.

Do czasu zainstalowania poprawki na CVE-2026-91403

• Dostęp sieciowy do usług Javy należy ograniczyć do systemów, które go potrzebują, zwłaszcza w przypadku usług przyjmujących połączenia TLS z internetu.
• Tam, gdzie to możliwe, warto kończyć połączenia TLS przed usługą Javy, na przykład w reverse proxy, aby do JSSE docierało mniej niezaufanych połączeń TLS. Zmniejsza to ekspozycję, ale nie zastępuje poprawki.
• Należy obserwować logi usług Javy dostępnych z internetu pod kątem nietypowych błędów TLS i awarii oraz mieć gotowe kopie zapasowe.

Co dalej

Oracle przeszedł w Javie na częstsze wydania bezpieczeństwa. Kolejne, Critical Security Patch Update, zaplanowano na 17 listopada 2026 r., a następny kwartalny Critical Patch Update na 19 stycznia 2027 r. Warto wpisać obie daty do kalendarza i za każdym razem powtórzyć trzy opisane wyżej kroki.

Jeśli nie są Państwo pewni, które systemy korzystają z Javy, lub usługa Javy mogła już zostać zaatakowana, pomogą nasze zespoły zarządzanych usług bezpieczeństwa i reagowania na incydenty.