Nowo zidentyfikowana podatność w oprogramowaniu IBM WebSphere otrzymała ocenę 7.5 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) [cve.cvss]. Problem dotyczy serwerów aplikacyjnych IBM WebSphere Application Server oraz IBM WebSphere Application Server Liberty [^1]. Luka umożliwia zdalne wykonanie kodu lub wywołanie odmowy usługi, co stanowi istotne ryzyko dla stabilności i bezpieczeństwa systemów opartych o tę technologię.

Rozwiązania IBM WebSphere historycznie znajdowały zastosowanie w dużych polskich organizacjach, w tym w sektorze finansowym i administracji publicznej. Choć nowsze projekty często bazują na innych stosach technologicznych, wiele krytycznych systemów wciąż działa w oparciu o tę platformę. Podatność ta jest więc sygnałem do przeprowadzenia wewnętrznego audytu zasobów IT.

TL;DR

  • Produkt: IBM WebSphere Application Server, IBM WebSphere Application Server Liberty [^1].
  • Komponent: Podatność zlokalizowano w komponencie WebSphere Web Server Plug-in [^2].
  • Wektor: Atakujący, podszywając się pod serwer aplikacji, wysyła spreparowaną odpowiedź do wtyczki serwera WWW [^3].
  • Identyfikator: CVE-2026-8858 [cve.id].
  • Skutek: Zdalne wykonanie kodu – RCE (Remote Code Execution — zdalne wykonanie kodu na komputerze ofiary) lub odmowa usługi – DoS (Denial of Service) [^1].
  • Kogo dotyczy: Organizacje, które wykorzystują serwery aplikacyjne IBM WebSphere, szczególnie w starszych, krytycznych systemach (sektor bankowy, ubezpieczeniowy, administracja publiczna).
  • Pierwszy ruch: Natychmiastowa weryfikacja, czy w infrastrukturze firmy wykorzystywany jest podatny komponent. Przygotowanie do wdrożenia aktualizacji od producenta.

Wektor ataku

Podatność oznaczona jako CVE-2026-8858 znajduje się w mechanizmie komunikacji między serwerem WWW a serwerem aplikacyjnym WebSphere [^2]. Atak nie jest trywialny i wymaga od atakującego znalezienia się w pozycji umożliwiającej przechwycenie lub wstrzyknięcie ruchu sieciowego.

Scenariusz ataku zakłada, że atakujący jest w stanie podszyć się pod serwer aplikacji [^3]. Może to osiągnąć np. poprzez atak typu MITM (Man-in-the-Middle – atak polegający na podsłuchaniu lub modyfikacji ruchu między dwiema stronami) lub poprzez kompromitację segmentu sieci, w którym odbywa się komunikacja.

Po uzyskaniu odpowiedniej pozycji w sieci, atakujący wysyła do komponentu WebSphere Web Server Plug-in specjalnie spreparowaną odpowiedź [^3]. Błędna obsługa tej odpowiedzi przez wtyczkę może prowadzić do jednego z dwóch skutków:

  1. Zdalne wykonanie kodu (RCE): Najpoważniejszy scenariusz, w którym atakujący może uruchomić dowolny kod z uprawnieniami procesu serwera aplikacyjnego. Daje to pełną kontrolę nad podatnym systemem.
  2. Odmowa usługi (DoS): Scenariusz, w którym spreparowana odpowiedź powoduje awarię wtyczki lub całego serwera, uniemożliwiając obsługę legalnego ruchu. Może to prowadzić do paraliżu kluczowych usług biznesowych.

Telemetria nie wskazuje jeszcze na aktywne wykorzystanie tej luki na szeroką skalę, jednak publikacja szczegółów technicznych może to zmienić.

Wskaźniki kompromitacji

Na ten moment nie są dostępne publiczne wskaźniki kompromitacji – IoC (Indicators of Compromise — wskaźniki kompromitacji: hashe plików, adresy IP, domeny). Rekomendujemy monitorowanie oficjalnych biuletynów bezpieczeństwa IBM w poszukiwaniu aktualizacji oraz ewentualnych reguł detekcyjnych dla systemów SIEM/EDR.

Co zrobić w 24-48h

Rekomendowane podejście zakłada działanie prewencyjne. Poniższe kroki nie zastępują pełnej konsultacji bezpieczeństwa, ale stanowią pierwszy, niezbędny ruch.

  1. Identyfikacja zasobów. Należy niezwłocznie przeprowadzić audyt infrastruktury w celu zidentyfikowania wszystkich instancji IBM WebSphere Application Server oraz WebSphere Application Server Liberty. Kluczowe jest potwierdzenie, czy wykorzystują one komponent WebSphere Web Server Plug-in.

  2. Ocena ryzyka w kontekście NIS2. Dla polskich firm, które są operatorami usług kluczowych lub dostawcami usług cyfrowych, identyfikacja i ocena tej luki jest elementem zgodności z dyrektywą NIS2 (unijna dyrektywa o bezpieczeństwie sieci, obowiązuje od 2024). Należy udokumentować proces oceny ryzyka dla systemów, w których podatność może występować.

  3. Przygotowanie do aktualizacji. Należy śledzić komunikaty bezpieczeństwa od IBM i przygotować plan wdrożenia odpowiednich łatek, gdy tylko zostaną udostępnione. W środowiskach produkcyjnych proces ten musi być poprzedzony testami na środowisku deweloperskim lub testowym.

  4. Wzmocnienie monitoringu. Zespoły SOC (Security Operations Center — zespół monitoringu bezpieczeństwa) powinny rozważyć tymczasowe wzmocnienie monitoringu ruchu sieciowego pomiędzy serwerami WWW a serwerami aplikacyjnymi WebSphere. Należy zwracać uwagę na wszelkie anomalie w komunikacji, nietypowe odpowiedzi lub próby nawiązania połączenia z nieautoryzowanych źródeł.

Zobacz też