Luka oznaczona identyfikatorem CVE-2026-35301 [^1] otrzymała maksymalną ocenę 10.0 w skali CVSS (Common Vulnerability Scoring System — skala 0–10 oceniająca powagę luki) [^2]. Dotyczy ona popularnego serwera aplikacji Oracle WebLogic Server, wykorzystywanego w wielu dużych organizacjach, w tym w polskim sektorze finansowym i administracji publicznej. Podatność jest trywialna w eksploitacji i nie wymaga uwierzytelnienia, co stawia wystawione do internetu instancje w sytuacji wysokiego ryzyka.

Podatność zlokalizowana jest w komponencie Console [^1]. Skuteczne wykorzystanie luki może prowadzić do całkowitego przejęcia kontroli nad serwerem [^3]. Co istotne, atak może również wpłynąć na inne systemy połączone z WebLogic Server [^4], co znacząco rozszerza potencjalną powierzchnię ataku wewnątrz organizacji.

TL;DR

  • Produkt: Oracle WebLogic Server, komponent Console [^1].
  • Podatne wersje: 12.2.1.4.0 oraz 14.1.1.0.0 [^5].
  • Wektor: Nieautoryzowany dostęp sieciowy przez protokół HTTP [^6]. Atak nie wymaga interakcji użytkownika ani żadnych uprawnień.
  • Zagrożenie: Zdalne wykonanie kodu (RCE — Remote Code Execution) i pełne przejęcie serwera [^3]. Wpływ na poufność, integralność i dostępność oceniono jako krytyczny [^7].
  • Wskaźniki kompromitacji (IoC): Obecnie brak publicznych, jednoznacznych wskaźników. Rekomendujemy monitorowanie logów dostępu do panelu administracyjnego pod kątem nietypowych zapytań.
  • Kogo dotyczy: Wszystkie organizacje, które używają podatnych wersji WebLogic Server. W polskim kontekście dotyczy to szczególnie dużych przedsiębiorstw, banków, firm telekomunikacyjnych i jednostek administracji państwowej.
  • Pierwszy ruch: Natychmiastowa identyfikacja wszystkich instancji WebLogic Server w infrastrukturze i weryfikacja ich wersji. Ograniczenie dostępu sieciowego do komponentu Console do absolutnego minimum.

Wektor ataku

Podatność CVE-2026-35301 to luka umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia. Atakujący potrzebuje jedynie dostępu sieciowego do instancji WebLogic Server, która udostępnia swój panel administracyjny (Console) przez HTTP [^6].

Analiza wektora CVSS dostarcza więcej szczegółów technicznych [^8]:

  • AV:N (Attack Vector: Network) – Atak może być przeprowadzony zdalnie przez sieć.
  • AC:L (Attack Complexity: Low) – Wykorzystanie luki jest proste, nie wymaga specjalistycznych narzędzi ani warunków.
  • PR:N (Privileges Required: None) – Atakujący nie musi posiadać żadnych uprawnień w systemie docelowym.
  • UI:N (User Interaction: None) – Atak nie wymaga żadnej akcji ze strony użytkownika lub administratora.
  • S:C (Scope: Changed) – Wykorzystanie luki w WebLogic Server może pozwolić na atak na inne komponenty infrastruktury, które z nim współpracują [^4]. To kluczowy element podnoszący ocenę do 10.0.
  • C:H, I:H, A:H (Confidentiality, Integrity, Availability: High) – Atak może mieć maksymalny wpływ na poufność, integralność i dostępność danych oraz samego serwera [^7].

Kombinacja tych czynników sprawia, że każda publicznie dostępna, niezałatana instancja WebLogic Server jest bezpośrednim celem. Spodziewamy się, że wkrótce mogą pojawić się publiczne exploity, a następnie masowe skanowanie internetu w poszukiwaniu podatnych serwerów.

Wskaźniki kompromitacji

Na dzień publikacji tego alertu nie istnieją publicznie dostępne, jednoznaczne wskaźniki kompromitacji (IoC — Indicators of Compromise), takie jak hashe plików czy adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny).

Zespoły SOC (Security Operations Center — zespół monitoringu bezpieczeństwa) powinny jednak natychmiast wdrożyć monitorowanie logów dostępu do serwera WWW i aplikacji WebLogic. Należy szukać nietypowych, długich lub zakodowanych zapytań kierowanych do ścieżek związanych z komponentem Console. Każde zapytanie do tego panelu pochodzące z nieznanego, publicznego adresu IP powinno być traktowane jako podejrzane.

# Przykładowe obszary do monitorowania w logach dostępu:
# - Żądania HTTP POST do ścieżki /console/.*
# - Żądania zawierające nietypowe nagłówki lub parametry.
# - Procesy potomne uruchamiane przez proces serwera WebLogic (np. /bin/sh, cmd.exe, powershell.exe).
# - Nietypowy ruch wychodzący z serwera aplikacyjnego do nieznanych adresów IP.

Co zrobić w 24-48h

Rekomendujemy podjęcie natychmiastowych działań w celu mitygacji ryzyka. Czas jest kluczowy, ponieważ publiczne exploity mogą pojawić się w każdej chwili.

  1. Identyfikacja zasobów: Przeprowadź pilny audyt swojej infrastruktury w celu zidentyfikowania wszystkich działających instancji Oracle WebLogic Server. Sprawdź ich wersje, aby potwierdzić, czy są podatne (12.2.1.4.0 lub 14.1.1.0.0) [^5].

  2. Ograniczenie dostępu (krytyczne): Jeśli panel administracyjny („Console”) jest dostępny z publicznego internetu, należy natychmiast ograniczyć do niego dostęp na poziomie zapory sieciowej. Dostęp powinien być limitowany wyłącznie do zaufanych adresów IP administratorów lub firmowej sieci VPN (Virtual Private Network). To najważniejszy krok, który może znacząco utrudnić atak.

  3. Aktualizacja: Wdróż oficjalne poprawki bezpieczeństwa wydane przez Oracle dla CVE-2026-35301, gdy tylko zostaną udostępnione. Planowanie okna serwisowego powinno być traktowane jako najwyższy priorytet. W kontekście polskiego biznesu, podmioty objęte dyrektywą NIS2 (unijna dyrektywa o bezpieczeństwie sieci) mają obowiązek zarządzania takimi ryzykami w sposób terminowy.

  4. Monitorowanie i poszukiwanie zagrożeń (Threat Hunting): Zleć zespołowi bezpieczeństwa aktywne poszukiwanie śladów kompromitacji. Przeanalizuj historyczne logi pod kątem podejrzanych zapytań do komponentu „Console”. Nawet jeśli system zostanie zaktualizowany, mógł zostać skompromitowany wcześniej.

Powyższe kroki stanowią rekomendowane podejście i nie zastępują pełnej analizy ryzyka ani konsultacji z ekspertami ds. bezpieczeństwa. W przypadku podejrzenia kompromitacji, należy uruchomić procedury reagowania na incydenty i rozważyć zgłoszenie do CSIRT NASK (CERT Polska).

Zobacz też