CVE-2026-91403: Krytyczna luka Oracle Java SE i GraalVM umożliwiająca zdalne ataki

Oracle wydał poza harmonogramem alert zabezpieczeń dotyczący CVE-2026-91403, krytyczną podatność wpływającą na Oracle Java SE, Oracle GraalVM dla JDK i Oracle GraalVM Enterprise Edition. Problem bezpieczeństwa występuje w komponencie Java Secure Socket Extension (JSSE) i ma wynik CVSS v3.1 wynoszący 9.1.

Podatność jest zdalnie eksploatowalna bez uwierzytelnienia. Według Oracle, atakujący z dostępem do sieci poprzez wiele protokołów może skompromitować podatne środowiska Java bez podawania poświadczeń lub konieczności interakcji użytkownika. Udało się, eksploatacja może odkryć dane krytyczne i umożliwić nieautoryzowane modyfikacje, tworzenie lub usuwanie informacji dostępnych dla dotkniętego środowiska Java.

Rapid7 klasyfikuje lukę jako krytyczną i potwierdza wektor CVSS CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Oznacza to, że eksploatacja może wystąpić przez sieć z niską złożonością ataku, nie wymaga uprawnień ani interakcji ofiary, a może mieć wysoki wpływ na poufność i integralność.

Szerokie wdrożenie Javy w usługach internetowych przedsiębiorstw, aplikacjach backendowych, oprogramowaniu pośredniczącym, API i infrastrukturze krytycznej biznesowo zwiększa potencjalne narażenie. Organizacje powinny zidentyfikować dotknięte środowiska Java i GraalVM oraz priorytetowo zainstalować poprawki z alertu zabezpieczeń Oracle.

Zespoły bezpieczeństwa szukające możliwości wykrywania CVE-2026-91403 powinny monitorować usługi Java pod kątem anormalnych interakcji sieciowych, niespodziewanych awarii certyfikatów lub związanych z TLS, podejrzanych procesów potomnych i nietypowego dostępu do wrażliwych danych aplikacji.

Platforma Inteligencji Wykrywania AI-Native SOC Prime może pomóc zespołom bezpieczeństwa w wzmocnieniu ich obrony przed eksploatacją nowych podatności za pomocą treści wykrywania mapowanych na MITRE ATT&CK® i dostępnych w różnych środowiskach SIEM, EDR i Data Lake.

Kliknij Odkryj Wykrycia aby uzyskać dostęp do odpowiedniej treści SOC i logiki łowieckiej. Aby wykryć CVE-2026-91403 i związane z tym zachowania po eksploatacji, obrońcy powinni łączyć telemetrykę aplikacji Java, monitorowanie sieci, widoczność punktów końcowych i dzienniki na poziomie serwisu.

Zespoły bezpieczeństwa mogą także używać Prime Architect do przekształcania nowych informacji o podatnościach w reguły Sigma, generowania zapytań łowieckich, walidacji logiki wykrywania i tłumaczenia wykryć na obsługiwane platformy bezpieczeństwa.

Skontaktuj się z Działem Sprzedaży

analiza CVE-2026-91403

CVE-2026-91403 wpływa na komponent JSSE używany przez aplikacje Java do zapewniania bezpiecznych komunikacji. Oracle opisuje lukę jako łatwo eksploatowalną i potwierdza, że ataki mogą pochodzić zdalnie przez wiele protokołów bez uwierzytelnienia.

Dostawca publicznie nie ujawnił podstawowego błędu programistycznego ani pełnej sekwencji eksploatacji. Polityka ujawniania podatności Oracle celowo ogranicza szczegóły techniczne, które mogłyby ułatwić uzbrojenie, gdy klienci wdrażają poprawki. Dlatego twierdzenia o specyficznym nieprawidłowym pakiecie, strukturze certyfikatu, argumencie API lub prymitu eksploatacji nie powinny być traktowane jako potwierdzone, chyba że Oracle opublikuje dodatkowe informacje techniczne.

CVE-2026-91403 wpływa na następujące wspierane wydania Oracle:

• Oracle Java SE 8u511 i 8u511-perf
• Oracle Java SE 11.0.33
• Oracle Java SE 17.0.21
• Oracle Java SE 21.0.13
• Oracle Java SE 25.0.5
• Oracle Java SE 27.0.1
• Oracle GraalVM dla JDK 17.0.21
• Oracle GraalVM dla JDK 21.0.13
• Oracle GraalVM Enterprise Edition 21.3.20

Oracle również ostrzega, że niewspierane wcześniejsze wydania nie były testowane, ale prawdopodobnie zawierają podatności uwzględnione w alercie zabezpieczeń. Organizacje nadal operujące na niewspieranych gałęziach Javy nie powinny zakładać, że są niepodatne.

Powierzchnia ataku jest szersza niż samodzielne aplikacje Java na komputerach stacjonarnych. Oracle szczególnie wskazuje, że eksploatacja może wystąpić poprzez API eksponowane przez podatny komponent, w tym sytuacje, w których usługa internetowa przekazuje dane kontrolowane przez atakującego do tych API.

Dostawca także zaznacza, że problem dotyczy wdrożeń Java, które wykonują nieufny kod, polegając na piaskownicy Java do ochrony, w tym uruchamianych w piaskownicy aplikacji Java Web Start i appletów Java.

Szczegóły CVE-2026-91403 pokazują szczególnie poważne konsekwencje dla poufności i integralności. Oracle ocenia oba wpływy jako wysokie, nie przypisując bezpośredniego wpływu na dostępność. Udany atakujący mógłby potencjalnie uzyskać nieautoryzowany dostęp do krytycznych danych aplikacji lub modyfikować, tworzyć i usuwać informacje dostępne dla skompromitowanego środowiska Java.

To rozróżnienie jest ważne dla reagowania na incydenty. Organizacje nie powinny skupiać się wyłącznie na zakłóceniach usług. Serwer podatny może nadal działać normalnie, podczas gdy dostępne są wrażliwe informacje lub dane aplikacji są modyfikowane.

W momencie publikacji ani Rapid7, ani Oracle nie dostarczają publicznie PoC CVE-2026-91403 ani wystarczających instrukcji technicznych eksploatacji do samodzielnego odtworzenia podatności. Rapid7 również wymienia kwestię jako nieobecną w katalogu Znanych Podatności Wykorzystywanych CISA na dzień 22 października 2026.

Podobnie, żadne specyficzne dla kampanii IOCs CVE-2026-91403, takie jak złośliwe adresy IP, domeny, skróty lub sygnatury ładunków, nie zostały opublikowane w głównych źródłach. To ogranicza skuteczność łowiectwa opartego wyłącznie na wskaźnikach i sprawia, że widoczność behawioralna jest bardziej istotna.

Zespoły bezpieczeństwa powinny monitorować usługi skierowane na Javę w celu wykrycia:

• Nieoczekiwanych żądań sieciowych docierających do aplikacji Java lub usług internetowych
• Nienormalnych błędów związanych z TLS lub JSSE
• Zmian w danych aplikacji bez odpowiadającej działalności legalnej
• Nieoczekiwanych anomalii uwierzytelnienia lub autoryzacji
• Procesów Java inicjujących nietypowe połączenia wychodzące
• Nierozpoznanych procesów potomnych uruchamianych przez aplikacje Java
• Modyfikacji plików, konfiguracji lub zasobów aplikacji
• Podejrzanych żądań API zaraz przed nienormalnym dostępem do danych

Ponieważ kompletne mechanizmy eksploatacji pozostają nieujawnione, te zachowania same w sobie nie mogą dowodzić eksploatacji. Powinny one służyć jako punkty startowe dochodzenia w połączeniu z narażeniem na podatność i specyficzną telemetrię aplikacji.

łagodzenie CVE-2026-91403

Oracle wydał dedykowany alert zabezpieczeń 21 października 2026, zamiast czekać na późniejszy zaplanowany cykl bezpieczeństwa. Administratorzy powinni jak najszybciej zainstalować poprawki wymienione w dokumentacji dostępności łatek Oracle.

Przedsiębiorstwa powinny najpierw zinwentaryzować wszystkie instalacje Javy, w tym środowiska uruchomieniowe zintegrowane z oprogramowaniem komercyjnym, produktami middleware, serwerami aplikacji, kontenerami, środowiskami developerskimi i urządzeniami zewnętrznymi. Komponenty Java osadzone wewnątrz innego produktu często są pomijane podczas zarządzania podatnościami, ponieważ administratorzy mogą nie zdawać sobie sprawy, że w katalogu aplikacji znajduje się oddzielny JDK lub JRE.

Priorytet powinny mieć systemy, które:

• Akceptują połączenia sieciowe z niebezpiecznych źródeł
• Wystawiają usługi internetowe lub API oparte na Javie
• Przetwarzają dane kontrolowane przez atakującego
• Przechowują wrażliwe dane biznesowe lub klientów
• Uruchamiają niewspierane wydania Java
• Używają Java Web Start lub innych modeli wdrożenia opartych na piaskownicy

Oracle zapewnia łatki z alertem zabezpieczeń tylko dla wersji objętych Premier Support lub Extended Support. Wcześniejsze wydania niekoniecznie są bezpieczne tylko dlatego, że są nieobecne w tabeli dotkniętych wersji. Oracle explicity recommend moving unsupported deployments to supported versions because older releases may also contain the vulnerability.

Jeżeli natychmiastowe wdrążenie łatek nie jest możliwe, organizacje powinny zmniejszyć narażenie przez ograniczenie dostępu sieciowego do dotkniętych usług, ograniczenie komunikacji do zaufanych systemów i stosowanie kontroli dostępu na poziomie aplikacji tam, gdzie to możliwe. Te kroki powinny być traktowane jako tymczasowe działania zmniejszające ryzyko, a nie zamienniki dla aktualizacji dostawcy.

Zespoły bezpieczeństwa powinny również retrospektywnie przeglądać dzienniki aplikacji i sieci. Wyszukuj nieoczekiwany dostęp do wrażliwych danych, podejrzane modyfikacje, anormalną aktywność sieciową Java i nietypowe żądania API, których nie można wyjaśnić legalnymi operacjami biznesowymi.

Jeśli zidentyfikowano podejrzane zachowania, osoby reagujące powinny:

• Izolować dotknięty host, gdzie to możliwe operacyjnie.
• Zachowywać dzienniki aplikacji Java, serwera sieciowego, punktu końcowego i sieci.
• Sprawdzać integralność wrażliwych danych aplikacji.
• Identyfikować poświadczenia, tajemnice i tokeny dostępne dla procesu Java.
• Rotować potencjalnie narażone poświadczenia.
• Wyszukiwać nieautoryzowane zmiany w plikach aplikacyjnych i konfiguracji.
• Analizuj połączenia wychodzące pod kątem oznak dalszej aktywności.
• Walidować inne systemy Java o tej samej konfiguracji aplikacji.

Ponieważ poufność i integralność są głównymi skutkami zidentyfikowanymi przez Oracle, odpowiedzi na incydenty powinny obejmować przeglądy dostępu do danych i modyfikacji danych, nawet gdy nie ma dowodów na przerwy w działaniu.

Organizacje korzystające z platformy inteligencji wykrywania AI-Native SOC Prime mogą wzmocnić monitorowanie behawioralne wokół podatnych usług Java, podczas gdy łaty są wdrażane, a także kontynuować polowanie na aktywność po kompromitacji w swoim stosie bezpieczeństwa.

Disclaimer: Zawartość wykrywania może nie być dostępna dla każdego CVE. Sprawdź platformę SOC Prime, aby uzyskać aktualne informacje. Jeśli odpowiednie wykrycia nie są jeszcze dostępne, sprawdzaj ponownie, gdy nowa inteligencja zagrożeń i treści wykrycia są ciągle dodawane.