Archiwa: NIST - Strona 60 z 69 - Security Bez Tabu

Tag: NIST

WatchGuard ostrzega przed aktywnie wykorzystywaną luką RCE w Firebox (CVE-2025-14733)

Wprowadzenie do problemu / definicja luki

WatchGuard opublikował ostrzeżenie dotyczące krytycznej podatności umożliwiającej zdalne wykonanie kodu (RCE) w zaporach Firebox. Luka została oznaczona jako CVE-2025-14733 i dotyczy komponentu iked w systemie Fireware OS (obsługa negocjacji IKE/IPsec, w szczególności IKEv2). Co ważne: producent potwierdził próby aktywnej eksploatacji „w naturze” (in the wild).

Z perspektywy obrony sieciowej to „klasa” podatności, której nie można traktować jak typowego błędu aplikacyjnego: przejęcie firewalla/VPN gatewaya często oznacza przejęcie „najbardziej uprzywilejowanego” punktu w infrastrukturze.

W skrócie

  • CVE: CVE-2025-14733
  • Typ: Out-of-bounds write → potencjalne RCE bez uwierzytelniania (pre-auth) w procesie iked
  • Warunki narażenia: konfiguracje Mobile User VPN (IKEv2) oraz Branch Office VPN (IKEv2) z dynamic gateway peer; dodatkowo podatność może się utrzymywać nawet po usunięciu konfiguracji (patrz sekcja techniczna).
  • Skala: dotyczy wielu gałęzi Fireware (11.x, 12.x, 2025.1) i szerokiej gamy modeli Firebox (w tym wirtualnych/chmurowych)
  • Ocena: WatchGuard podaje CVSS 9.3 (CVSS v4), a NVD prezentuje także CVSS 3.1 = 9.8.
  • Fix: aktualizacja do wersji naprawionych (m.in. 2025.1.4, 12.11.6, 12.5.15, 12.3.1 Update 4) – szczegóły niżej.
  • Sygnały ataku (przykłady): nietypowe logi IKE_AUTH/certyfikatów oraz zawieszenia/crashe procesu iked; WatchGuard opublikował też IP powiązane z aktywnością atakujących.
  • KEV: CISA poinformowała o dodaniu CVE-2025-14733 do katalogu Known Exploited Vulnerabilities (KEV).

Kontekst / historia / powiązania

Wątek „RCE w IKE/IKEv2 na bramach VPN” wraca cyklicznie w branży – jest to atrakcyjny wektor, bo usługa VPN bywa wystawiana do internetu i obsługuje złożone formaty danych (negocjacje, certyfikaty, payloady). W przypadku WatchGuard warto zauważyć, że firma wcześniej łatała bardzo podobny problem RCE w Firebox (CVE-2025-9242), a później obserwowano dużą liczbę urządzeń pozostających podatnych.

Dla obrony oznacza to jedno: nawet jeśli Twoja organizacja „zwykle patchuje”, urządzenia brzegowe trzeba traktować jako absolutny priorytet (bo okno pomiędzy publikacją poprawek a masową eksploatacją bywa krótkie).

Analiza techniczna / szczegóły luki

Co dokładnie jest podatne?

Podatność jest opisana jako out-of-bounds write w procesie iked w WatchGuard Fireware OS. Taki błąd to w praktyce korupcja pamięci, która w sprzyjających warunkach może prowadzić do wykonania kodu (RCE).

Jakie konfiguracje są krytyczne?

WatchGuard wskazuje, że problem dotyczy:

  • Mobile User VPN z IKEv2, oraz
  • Branch Office VPN z IKEv2 skonfigurowanych z dynamic gateway peer.

Istotny „haczyk”: jeśli Firebox wcześniej miał skonfigurowany Mobile User VPN IKEv2 lub BOVPN IKEv2 do dynamicznego peera, a potem te wpisy usunięto, urządzenie wciąż może pozostać podatne, jeżeli nadal skonfigurowany jest BOVPN do static gateway peer. To sugeruje, że sama „czystość” konfiguracji w GUI nie zawsze domyka powierzchnię ataku (np. pozostają aktywne ścieżki kodu/usługi).

Wersje podatne i wersje naprawione

Zgodnie z opisem producenta oraz wpisem w NVD, podatne są m.in. zakresy:

  • 11.10.2 → 11.12.4_Update1
  • 12.0 → 12.11.5
  • 2025.1 → 2025.1.3

Wersje naprawione (wg tabeli „Resolution” WatchGuard):

  • 2025.1 → 2025.1.4
  • 12.x → 12.11.6
  • 12.5.x (modele T15 i T35) → 12.5.15
  • 12.3.1 (FIPS) → 12.3.1_Update4 (B728352)
  • 11.x → End of Life (czyli bez dalszych poprawek).

IOC/IoA – jak wygląda telemetria ataków?

WatchGuard opublikował „Indicators of Attack”, które są szczególnie przydatne operacyjnie, bo pozwalają szybciej triagować incydent:

Adresy IP powiązane z aktywnością atakujących – WatchGuard podkreśla, że połączenia wychodzące do tych IP są mocnym wskaźnikiem kompromitacji, a przychodzące mogą sugerować rekonesans/eksploatację:

  • 45.95.19[.]50
  • 51.15.17[.]89
  • 172.93.107[.]67
  • 199.247.7[.]82

Przykładowe logi IKE (IoA):

  • komunikat o zbyt długim łańcuchu certyfikatów („…longer than 8…”) przy IKE2 Auth payload z >8 certyfikatami, oraz
  • log IKE_AUTH z nienaturalnie dużym CERT payload (wskazany próg >2000 bajtów).

Zachowanie urządzenia (telemetria):

  • podczas udanej eksploatacji proces iked może się zawieszać (zrywanie negocjacji/rekey),
  • po próbie udanej lub nieudanej proces iked może crashować i generować fault report.

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska możliwość zdalnego wykonania kodu na firewallu/VPN gatewayu, konsekwencje zwykle wykraczają poza „jeden serwer mniej”:

  • przejęcie punktu styku z internetem (brzeg infrastruktury),
  • pivot do sieci wewnętrznej i segmentów „za firewallem”,
  • potencjalna manipulacja regułami, trasowaniem, a nawet obserwacja/zakłócanie tuneli VPN,
  • ryzyko kradzieży danych uwierzytelniających przechowywanych lokalnie oraz eskalacji do domeny/SSO (zależnie od integracji). (To są typowe scenariusze dla kompromitacji bram VPN; konkretne kroki zależą od tego, co napastnik zrobi po uzyskaniu kontroli).

NHS England ocenia dalszą eksploatację jako prawdopodobną i rekomenduje pilne zastosowanie poprawek zgodnie z advisory producenta.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista „co robić dziś”, ułożona pod realia SOC/infra.

1) Patch (priorytet #1)

  • Zidentyfikuj wersje Fireware w całej flocie (również instancje wirtualne/chmurowe).
  • Aktualizuj do wersji naprawionych: 2025.1.4 / 12.11.6 / 12.5.15 / 12.3.1_Update4 (zgodnie z gałęzią).
  • Jeśli masz 11.x – to EOL. Tu „patch” może oznaczać migrację/upgrade sprzętu/wersji, bo poprawki nie będą dostępne.

2) Ogranicz ekspozycję IKEv2 (jeśli musisz chwilę poczekać z patchem)

Jeśli z powodów operacyjnych patchowanie wymaga okna serwisowego:

  • ogranicz dostęp do usług VPN/IKEv2 tylko do zaufanych adresów/peerów (polityki/ACL, geofencing jeśli pasuje do profilu ryzyka),
  • przejrzyj konfiguracje dynamic gateway peer i usuń/wyłącz nieużywane,
  • rozważ czasowe wyłączenie najbardziej ryzykownych ścieżek (zależnie od tego, jak masz zestawione BOVPN).

WatchGuard opisuje też tymczasowe działania dla środowisk z BOVPN, gdy nie da się natychmiast zaktualizować (m.in. wyłączenie dynamic peer BOVPN i korekta polityk).

3) Hunting/IR: sprawdź IoA/IOC

  • Przeskanuj logi pod kątem komunikatów o „peer certificate chain > 8” oraz IKE_AUTH z dużym CERT payload.
  • Sprawdź firewall/flow/EDR/NDR pod kątem połączeń wychodzących do wskazanych IP (to ma być „mocny” sygnał kompromitacji).
  • Zwróć uwagę na nietypowe crashe/zawieszenia iked (zrywanie renegocjacji, rekey, fault reports).

4) Rotacja sekretów po wykryciu śladów aktywności

Jeśli potwierdzisz podejrzaną aktywność/kompromitację, producent rekomenduje rotację lokalnie przechowywanych sekretów na podatnych urządzeniach (PSK, hasła, klucze/certy – zależnie od użycia).

5) Priorytetyzacja ryzyka

CISA sygnalizuje, że CVE-2025-14733 trafiło do katalogu KEV, co w praktyce oznacza: „to nie jest teoretyczne, to jest wykorzystywane”. W wielu organizacjach to automatycznie powinno podbić priorytet w procesie zarządzania podatnościami.

Różnice / porównania z innymi przypadkami

Najbliższym punktem odniesienia jest wspomniana wcześniej podatność CVE-2025-9242 – również dotycząca Firebox/Fireware i również opisywana jako bliska „rodzina” problemów RCE w okolicach IKE/iked. BleepingComputer zwraca uwagę, że obecna luka pojawia się niedługo po tamtym incydencie i że historycznie liczba niezałatanych urządzeń bywała wysoka.

Wniosek praktyczny: jeśli w Twojej organizacji Firebox jest traktowany jako „appliance, którego nie ruszamy”, to jest dokładnie ten moment, by zmienić podejście (SLA na łatki dla edge).

Podsumowanie / kluczowe wnioski

  • CVE-2025-14733 to krytyczna, aktywnie wykorzystywana podatność typu out-of-bounds write w iked (IKEv2) w WatchGuard Fireware OS, umożliwiająca pre-auth RCE.
  • Ryzyko dotyczy szerokiego spektrum wersji i urządzeń; szczególnie problematyczne są środowiska na 11.x (EOL).
  • WatchGuard udostępnił konkretne IoA (logi, zachowanie procesu, IP), które warto natychmiast wykorzystać w SOC.
  • Najszybsza i najpewniejsza droga redukcji ryzyka to aktualizacja do wersji naprawionych i ograniczenie ekspozycji IKEv2 tam, gdzie to możliwe.

Źródła / bibliografia

  1. WatchGuard PSIRT – WGSA-2025-00027 (CVE-2025-14733, wersje podatne/naprawione, IoA/IOC). (WatchGuard)
  2. BleepingComputer – informacja o aktywnej eksploatacji, kontekst (m.in. CVE-2025-9242) i działania tymczasowe. (BleepingComputer)
  3. NVD (NIST) – wpis CVE (opis, zakres wersji, metryki, daty publikacji). (nvd.nist.gov)
  4. NHS England Digital – alert o eksploatacji i zalecenia remediacji. (NHS England Digital)
  5. CISA Cyber (X) – komunikat o dodaniu CVE-2025-14733 do KEV. (X (formerly Twitter))

Ponad 25 tys. urządzeń Fortinet z włączonym FortiCloud SSO wystawionych na zdalne ataki – co oznaczają CVE-2025-59718 i CVE-2025-59719

Wprowadzenie do problemu / definicja luki

W grudniu 2025 r. zwrócono uwagę na bardzo niebezpieczny scenariusz: tysiące urządzeń Fortinet (m.in. FortiOS/FortiGate, FortiProxy, FortiSwitchManager oraz FortiWeb) ma włączoną funkcję “Allow administrative login using FortiCloud SSO” i jednocześnie wystawiony na Internet panel administracyjny. Internetowe skany wskazały ponad 25 000 takich adresów IP, co przy aktywnych próbach nadużyć przekłada się na realne ryzyko przejęcia kont administracyjnych i wycieku konfiguracji.

Rdzeniem problemu są dwie podatności:

  • CVE-2025-59718 – dotyczy wielu produktów (w praktyce: FortiOS/FortiProxy/FortiSwitchManager) i pozwala ominąć uwierzytelnianie FortiCloud SSO,
  • CVE-2025-59719 – analogiczny wektor dla FortiWeb.

W obu przypadkach chodzi o błędną weryfikację podpisu kryptograficznego w przepływie SAML (klasa błędu CWE-347), co umożliwia atakującemu obejście logowania SSO bez posiadania prawidłowych poświadczeń.

W skrócie

  • Skala ekspozycji: Shadowserver raportował >25 tys. IP z “odciskiem” FortiCloud SSO; w samych USA ~5,4 tys., w Indiach ~2 tys.
  • Aktywne nadużycia: Arctic Wolf obserwował intruzje z użyciem “malicious SSO logins” od 12 grudnia 2025.
  • Typowy ciąg ataku: udane logowanie admin przez SSO → eksport/ściągnięcie pliku konfiguracji przez GUI.
  • Priorytet naprawy: CISA dodała CVE-2025-59718 do KEV 16 grudnia 2025, a w NVD widać termin działań do 23 grudnia 2025 (kontekst KEV).

Kontekst / historia / powiązania

Warto podkreślić jedną rzecz, która ułatwia przeoczenie ryzyka w organizacjach: FortiCloud SSO nie musi być włączone “od zawsze”.

CERT Polska zwraca uwagę, że funkcja jest domyślnie wyłączona, ale w praktyce bywa automatycznie włączana podczas rejestracji urządzenia w FortiCare z poziomu GUI, jeśli administrator nie odznaczy odpowiedniej opcji.

W tym samym czasie (grudzień 2025) obserwujemy typowy “pattern” dla urządzeń brzegowych (edge): szybkie przejście od publikacji poprawek do masowych skanów i prób nadużyć, szczególnie gdy panel administracyjny jest dostępny z Internetu. W omawianym incydencie potwierdzono także, że liczba instancji z włączonym SSO i widocznym GUI jest zaskakująco duża.

Analiza techniczna / szczegóły luki

Na czym polega podatność?

Z technicznego punktu widzenia obie podatności sprowadzają się do tego, że urządzenie akceptuje spreparowaną odpowiedź SAML w procesie FortiCloud SSO, ponieważ weryfikacja podpisu kryptograficznego jest niewłaściwa (CWE-347). Skutkiem jest obejście uwierzytelniania – atakujący może uzyskać sesję administracyjną bez prawidłowego logowania.

Co robią atakujący w praktyce?

BleepingComputer oraz Arctic Wolf opisują spójny schemat:

  1. logowanie do panelu jako admin metodą SSO z nietypowego adresu źródłowego,
  2. następnie akcja przez GUI typu download/export system configuration,
  3. a dalej – analiza konfiguracji (interfejsy, polityki, usługi wystawione na Internet, hashe haseł).

Arctic Wolf opublikował też przykładowe adresy źródłowe (IOC) powiązane z obserwowanymi, złośliwymi logowaniami SSO oraz wskazał, że ruch pochodził z wybranych dostawców hostingu.

Jakie wersje są podatne i jakie są “fixed”?

Kanadyjskie Cyber Centre podaje jednoznacznie, do jakich wersji należy zaktualizować systemy (przykłady):

  • FortiOS: 7.6.4+, 7.4.9+, 7.2.12+, 7.0.18+
  • FortiProxy: 7.6.4+, 7.4.11+, 7.2.15+, 7.0.22+
  • FortiSwitchManager: 7.2.7+, 7.0.6+
  • FortiWeb: 8.0.1+, 7.6.5+, 7.4.10+

Praktyczne konsekwencje / ryzyko

Najbardziej “toksyczny” element tego typu incydentów to pobranie konfiguracji. Taki plik potrafi ujawnić:

  • topologię i podsieci (network layout),
  • reguły firewall / polityki,
  • listę usług wystawionych na Internet,
  • konta administracyjne i artefakty uwierzytelniania (w tym hashe, które w sprzyjających warunkach da się łamać offline).

W praktyce oznacza to, że nawet jeśli atakujący “tylko” zaloguje się i ściągnie konfigurację, konsekwencje mogą być długofalowe: dalsza eskalacja, pivot do sieci wewnętrznej, przygotowanie kampanii ransomware albo trwałe utrzymanie dostępu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej playbook w kolejności, która zwykle działa najlepiej operacyjnie:

  1. Zidentyfikuj ekspozycję GUI
    • Czy panel administracyjny (HTTPS/GUI) jest dostępny z Internetu?
    • Jeśli tak: ogranicz dostęp (VPN / allowlista / segmentacja), zanim przejdziesz dalej.
  2. Natychmiast aktualizuj do wersji naprawionych
    • Kieruj się listą “Solution/Upgrade to …” podaną przez Cyber Centre (sekcja powyżej).
  3. Tymczasowo wyłącz logowanie FortiCloud SSO (jeśli nie możesz od razu zaktualizować)
    • CERT Polska oraz Arctic Wolf wskazują możliwość wyłączenia FortiCloud SSO także z CLI:config system global set admin-forticloud-sso-login disable end
  4. Sprawdź logi pod kątem wzorca nadużycia
    • Szukaj zdarzeń typu “admin login successful” z metodą sso oraz krótkiej sekwencji działań administracyjnych po logowaniu (np. pobranie konfiguracji przez GUI).
    • Porównaj adresy źródłowe z IOC publikowanymi przez Arctic Wolf.
  5. Higiena poincydentowa (jeśli widzisz oznaki kompromitacji)
    • rotacja haseł admin, przegląd kont i uprawnień,
    • weryfikacja zmian w konfiguracji i regułach,
    • jeśli plik konfiguracyjny mógł wyciec: traktuj to jako wyciek informacji wrażliwych i dostosuj model zagrożeń (np. zmiana kluczy/sekretów, przegląd ekspozycji usług).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W tym przypadku szczególnie istotne są dwie różnice względem “klasycznych” luk w GUI/SSL-VPN:

  • Warunek aktywacji wektora: atak dotyczy sytuacji, gdy jest włączona funkcja FortiCloud SSO dla logowania administracyjnego (co może się stać “przy okazji” rejestracji w FortiCare).
  • Wektor SAML/SSO: zamiast błędu w endpointach webowych, problem siedzi w obsłudze i weryfikacji SAML, co ułatwia tworzenie “logic exploitów” (obejścia), a niekoniecznie typowych exploitów pamięciowych.

Podsumowanie / kluczowe wnioski

  • Jeśli masz produkty Fortinet i kiedykolwiek rejestrowałeś je w FortiCare, sprawdź, czy nie jest włączone FortiCloud SSO dla logowania admina.
  • Traktuj tę sprawę jako pilną: potwierdzono aktywne nadużycia (od 12 grudnia 2025), a CVE-2025-59718 trafiło do kontekstu KEV (16 grudnia 2025; termin działań do 23 grudnia 2025 w NVD).
  • “Must-have” to: patch + ograniczenie dostępu do GUI + weryfikacja logów pod kątem logowań SSO i eksportów konfiguracji.

Źródła / bibliografia

  1. BleepingComputer – skala ekspozycji i kontekst Shadowserver/SSO fingerprinting (BleepingComputer)
  2. Arctic Wolf – obserwacje nadużyć, IOCs, przykładowe logi oraz wersje naprawione (Arctic Wolf)
  3. CERT Polska (moje.cert.pl) – opis warunku włączenia SSO i rekomendacje + CLI (moje.cert.pl)
  4. NVD (NIST) – opis CVE-2025-59718 oraz adnotacja dot. KEV/due date (nvd.nist.gov)
  5. Canadian Centre for Cyber Security – alert AL25-019 z listą wersji i zaleceń (Canadian Centre for Cyber Security)

HPE łata krytyczną lukę RCE w OneView. Co muszą zrobić administratorzy już dziś?

Wprowadzenie do problemu / definicja luki

Hewlett Packard Enterprise (HPE) opublikowało poprawki dla krytycznej luki zdalnego wykonania kodu (RCE) w oprogramowaniu HPE OneView – centralnej platformie do zarządzania infrastrukturą (serwery, pamięci, sieć). Luka otrzymała identyfikator CVE-2025-37164 i ocenę maksymalną CVSS 10.0 (bez uwierzytelnienia, atak zdalny, pełny wpływ na poufność/spójność/dostępność).

W skrócie

  • Produkt: HPE OneView (wielowydaniowe wersje poniżej 11.0).
  • CVE: CVE-2025-37164, CVSS: 10.0 (maks.).
  • Wektor: zdalny, bez uwierzytelnienia, prowadzi do RCE.
  • Status: poprawki dostępne; brak obejść/mitigacji poza aktualizacją.
  • Działanie: natychmiastowa aktualizacja do najnowszej wersji/instalacja hotfixów HPE.

Kontekst / historia / powiązania

HPE OneView bywa krytycznym elementem w środowiskach data center i chmur prywatnych. W 2025 r. HPE publikowało już kilka istotnych biuletynów bezpieczeństwa (m.in. StoreOnce oraz komponenty OneView), jednak CVE-2025-37164 jest pierwszym przypadkiem w tym roku z maksymalnym scoringiem dla tego produktu. O luce poinformowały równolegle renomowane serwisy i dostawcy usług bezpieczeństwa.

Analiza techniczna / szczegóły luki

  • Charakter podatności: błąd umożliwiający zdalne wykonanie dowolnego kodu w kontekście usługi aplikacyjnej OneView. NVD klasyfikuje go w kategorii CWE-94 (Improper Control of Code Generation).
  • Zakres wersji: zgodnie z analizą branżową, narażone są wydania < 11.0, w tym linia 5.20–10.20, o ile nie zastosowano dedykowanych hotfixów (dla wirtualnego appliance i HPE Synergy). Dokładny zakres i linki do łatek znajdują się w biuletynie HPE.
  • Warunki ataku: atak zdalny, bez interakcji użytkownika i bez uwierzytelnienia; skutkuje pełnym kompromisem aplikacji zarządzającej, a w konsekwencji potencjalnie całej infrastruktury podłączonej do OneView.

Praktyczne konsekwencje / ryzyko

Udane wykorzystanie CVE-2025-37164 może pozwolić napastnikowi na:

  • przejęcie panelu zarządzania OneView;
  • eskalację do operacji na serwerach, zasobach pamięci i sieciach zarządzanych przez OneView;
  • pełny dostęp do danych konfiguracyjnych oraz możliwość wstrzyknięcia złośliwych obrazów/konfiguracji w skali całego klastra.
    Ze względu na brak wymogu uwierzytelnienia, luka jest wysoce robakowalna w środowiskach o odsłoniętym interfejsie.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja do HPE OneView 11.0 (lub nowszej, jeśli dostępna) albo instalacja najnowszych hotfixów dla posiadanej gałęzi (appliance / HPE Synergy) zgodnie z biuletynem HPE.
  2. Brak obejść: HPE i niezależne źródła wskazują, że nie ma skutecznych mitigacji poza patchowaniem.
  3. Higiena ekspozycji: natychmiast ogranicz dostęp do interfejsów OneView (segmentacja, ACL, VPN, IP allowlist), zablokuj dostęp z sieci publicznej.
  4. Detekcja/IR:
    • przegląd logów OneView i systemów zależnych pod kątem nietypowych żądań/akcji administracyjnych;
    • w razie opóźnionej aktualizacji – rozważ reset zaufania (zmiana poświadczeń, regeneracja certyfikatów, weryfikacja integralności obrazów firmware).
  5. Skany aktywów: użyj skanera zasobów/VM do identyfikacji hostów z wersjami < 11.0 i automatyzuj remediację (np. playbook Ansible). Wskazówki dot. detekcji wersji i zgodności publikują również firmy security.

Różnice / porównania z innymi przypadkami

W 2025 r. HPE łatało także inne krytyczne błędy (np. w StoreOnce), ale nie wszystkie miały wektor PR:N/UI:N/AV:N prowadzący do natychmiastowego RCE bez uwierzytelnienia. CVE-2025-37164 jest przez to priorytetem 1 – porównawczo bardziej ryzykownym niż luki wymagające uwierzytelnienia czy interakcji.

Podsumowanie / kluczowe wnioski

  • CVE-2025-37164 (CVSS 10.0) w HPE OneView to krytyczna podatność umożliwiająca zdalne RCE bez logowania.
  • Jedyną skuteczną obroną jest aktualizacja/hotfix – działaj natychmiast w środowiskach produkcyjnych.
  • Ogranicz ekspozycję interfejsów zarządzających i przeprowadź przegląd logów/konfiguracji pod kątem nadużyć.

Źródła / bibliografia

  • SecurityWeek: „HPE Patches Critical Flaw in IT Infrastructure Management Software” (18 grudnia 2025). (SecurityWeek)
  • HPE Security Bulletin: „HPE OneView Software – Remote Code Execution (CVE-2025-37164)” (grudzień 2025). (support.hpe.com)
  • NVD (NIST): karta CVE-2025-37164, CVSS, CWE-94. (nvd.nist.gov)
  • Rapid7: „CVE-2025-37164 – unauthenticated RCE affecting HPE OneView” (grudzień 2025). (Rapid7)
  • BleepingComputer: „HPE warns of maximum severity RCE flaw in OneView software” (grudzień 2025). (BleepingComputer)

UEFI: błąd w płytach głównych Asrock, Asus, Gigabyte i MSI umożliwia ataki DMA we wczesnym rozruchu

Wprowadzenie do problemu / definicja luki

W płytach głównych wielu wiodących producentów (ASRock, Asus, Gigabyte, MSI) wykryto podatność umożliwiającą ataki DMA na bardzo wczesnym etapie rozruchu (pre-boot). Choć firmware sygnalizuje aktywne zabezpieczenie DMA, w rzeczywistości IOMMU nie jest poprawnie inicjalizowane do momentu tuż przed przekazaniem kontroli systemowi operacyjnemu. W efekcie złośliwe urządzenie PCIe z dostępem fizycznym może czytać/pisać pamięć przed startem OS i jego mechanizmów ochronnych.

W skrócie

  • Dotyczy: wybranych modeli płyt głównych ASRock, Asus, Gigabyte, MSI. Inni dostawcy firmware (AMI, Insyde, Phoenix), producenci CPU (Intel, AMD) i Supermicro zgłaszają „nie dotyczy” w ramach tego problemu.
  • Identyfikatory: m.in. CVE-2025-11901, CVE-2025-14302, CVE-2025-14303, CVE-2025-14304 (różne warianty u poszczególnych vendorów).
  • Wektor ataku: fizyczny dostęp i wpięcie złośliwego urządzenia PCIe (np. karta z DMA).
  • Skutki: odczyt/zapis pamięci w fazie pre-boot, możliwość pozyskania tajnych danych i wstrzyknięcia kodu przed rozruchem.
  • Odkrycie i koordynacja: badacze Riot Games; koordynacja przez CERT/CC (Carnegie Mellon).
  • Status poprawek: producenci publikują aktualizacje BIOS/UEFI; w przypadku Gigabyte dostępne dla wielu rodzin (Intel 600/700/800; AMD 600/800; TRX50 zapowiedziane na Q1 2026).

Kontekst / historia / powiązania

CERT/CC opublikował notę VU#382314 17 grudnia 2025 r., dokumentując problem i status dostawców. Wpisy producentów płyt oraz wpisy NVD/CVE uszczegóławiają, które serie są objęte (np. Asus: Z490–Z790 i W790) oraz jakie CVE przypisano poszczególnym wariantom (np. MSI: CVE-2025-14303). Wykrycie przez zespół Riot ma także konsekwencje dla antycheatów – dziura podważała zaufanie do „Pre-Boot DMA Protection”, a Riot zapowiedział egzekwowanie aktualizacji firmware u graczy.

Analiza techniczna / szczegóły luki

Mechanizm Pre-Boot DMA Protection polega na użyciu IOMMU do izolacji urządzeń DMA już podczas rozruchu. W dotkniętych implementacjach UEFI występuje rozjazd między raportem a stanem faktycznym: firmware twierdzi, że ochrona DMA jest aktywna, ale IOMMU nie jest w pełni skonfigurowane aż do bardzo późnego etapu rozruchu. Ta „luka czasowa” pozwala urządzeniu PCIe na dostęp do pamięci fizycznej (R/W) przed inicjalizacją zabezpieczeń OS, co klasyfikowane jest jako CWE-693: Protection Mechanism Failure.

W przypadku MSI błąd ujęto właśnie jako Protection Mechanism Failure (CVE-2025-14303) – niepoprawne włączenie IOMMU umożliwia nieautoryzowany DMA w fazie pre-boot.

Praktyczne konsekwencje / ryzyko

  • Wymóg fizycznego dostępu ogranicza skalę ataków, ale ryzyko jest realne w środowiskach o podwyższonym zagrożeniu (colo, laboratoria, stanowiska serwisowe, stanowiska VIP), gdzie złośliwe peryferia mogą zostać dyskretnie podłączone.
  • Pre-boot code injection podważa integralność łańcucha rozruchu i może umożliwić trwałe ominięcie kontroli bezpieczeństwa na poziomie OS/hypervisora, a w środowiskach wirtualnych wpływać na izolację i delegację zaufania.
  • Ekosystem gier/anticheat: luka otwierała drogę do sprzętowych cheatów działających poza zasięgiem typowych detektorów; wydawcy mogą wymagać aktualizacji BIOS/UEFI.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizuj BIOS/UEFI do wersji oznaczonych jako naprawiające problem (sprawdź tabelę/biuletyn producenta swojej płyty).
    • Gigabyte: poprawki opublikowane dla licznych rodzin (Intel 600/700/800; AMD 600/800), TRX50 – Q1 2026.
    • MSI: śledź doradztwa bezpieczeństwa i wpis CVE-2025-14303.
    • Asus: zaktualizuj BIOS dla serii Z490–Z790/W790 i w BIOS ustaw IOMMU DMA Protection na „Enable with Full Protection”.
  2. Zweryfikuj ustawienia IOMMU/VT-d po aktualizacji (nie „Auto”). Jeśli producent przewiduje tryb „Full Protection” / „Enable during boot”, włącz go ręcznie.
  3. Zarządzaj dostępem fizycznym: ogranicz możliwość podpinania urządzeń PCIe/Thunderbolt, stosuj plombowanie obudów, kontroluj porty w strefach o podwyższonym ryzyku.
  4. Higiena łańcucha rozruchu: weryfikuj Secure Boot, rejestry zdarzeń rozruchu, integrację z EDR/HVCI; po krytycznych aktualizacjach przeprowadź rekonsyliację stanów bezpieczeństwa. (Zalecenie ogólne na bazie dobrych praktyk.)
  5. Środowiska VDI/hiperwizora: po poprawkach wykonaj testy izolacji urządzeń passthrough i vIOMMU, bo błąd dotyczył właśnie wczesnej fazy inicjalizacji.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do wcześniejszych problemów Secure Boot/UEFI (np. klasyczne obejścia Secure Boot czy „Hydroph0bia”), obecna podatność nie polega na złamaniu podpisów czy list zaufania, lecz na oknie czasowym w inicjalizacji IOMMU – czyli ochrony przed DMA. To ataki sprzętowe z fizycznym wektorem, które uderzają w fundament izolacji pamięci zanim OS wystartuje.

Podsumowanie / kluczowe wnioski

  • Błąd w implementacjach UEFI sprawia, że IOMMU nie chroni pamięci wystarczająco wcześnie, co otwiera drogę do pre-boot DMA.
  • Ryzyko dotyczy wybranych płyt Asrock/Asus/Gigabyte/MSI; inni kluczowi dostawcy zgłosili brak wpływu.
  • Aktualizacje BIOS/UEFI już są dostępne (publikowane sukcesywnie) – po aktualizacji wymuś tryb pełnej ochrony IOMMU.
  • W środowiskach o niższym zaufaniu fizycznym priorytetem jest patching i polityki kontroli dostępu do portów/slotów.

Źródła / bibliografia

  • SecurityWeek: „UEFI Vulnerability in Major Motherboards Enables Early-Boot Attacks” (18 grudnia 2025). (SecurityWeek)
  • CERT/CC VU#382314: „Vulnerability in UEFI firmware modules prevents IOMMU initialization…” (17 grudnia 2025). (kb.cert.org)
  • Riot Games (Vanguard): „Security Update: Closing the Pre-Boot Gap” (grudzień 2025). (Riot Games)
  • Gigabyte – Security Advisory „Vulnerability in UEFI Firmware Modules Prevents IOMMU Initialization…” (17 grudnia 2025). (GIGABYTE)
  • NVD – CVE-2025-14303 (MSI) – opis i metryki. (nvd.nist.gov)

113 tys. osób dotkniętych wyciekiem danych w Richmond Behavioral Health Authority (Virginia)

Wprowadzenie do problemu / definicja luki

Publiczna jednostka ochrony zdrowia psychicznego Richmond Behavioral Health Authority (RBHA) z Richmond w stanie Wirginia poinformowała o poważnym naruszeniu bezpieczeństwa danych. Atakujący uzyskali nieuprawniony dostęp do systemów, wykradli dane ponad 113 000 osób i wdrożyli ransomware, co mogło zakłócić dostępność usług. Ujawnione informacje obejmują m.in. imiona i nazwiska, numery Social Security, dane finansowe oraz informacje medyczne (PHI).

W skrócie

  • Skala: 113 232 osób objętych naruszeniem (RBHA).
  • Linia czasu: nieautoryzowany dostęp wykryto około 30 września 2025 r.; następnie rozpoczęto dochodzenie i powiadomienia.
  • Zakres danych: PHI, SSN, możliwie numery paszportów i informacje o kontach finansowych.
  • Taktyka: kradzież danych + wdrożenie ransomware w sieci RBHA.
  • Podstawa prawna: obowiązki notyfikacyjne wg prawa Wirginii dla naruszeń danych medycznych.

Kontekst / historia / powiązania

RBHA to agencja publiczna świadcząca usługi z zakresu zdrowia psychicznego, leczenia uzależnień i wsparcia osób z niepełnosprawnościami na terenie miasta Richmond. W sektorze ochrony zdrowia w USA ataki ransomware i wycieki PHI pozostają trendem rosnącym – wpis RBHA pojawia się w doniesieniach branżowych oraz zestawieniach incydentów zdrowotnych.

Analiza techniczna / szczegóły luki

Wektor i przebieg: według RBHA i relacji branżowych, incydent polegał na nieautoryzowanym dostępie do systemów, następnie ekstrakcji danych i uruchomieniu ransomware. Taki łańcuch (data theft → encryption/impact) odzwierciedla obecny model „double-extortion”, gdzie wyciek jest dźwignią do wymuszenia okupu.

Kategorie danych objętych ryzykiem:

  • identyfikacyjne: imię i nazwisko, SSN, czasem numery paszportów;
  • finansowe: informacje o kontach;
  • medyczne: chronione informacje zdrowotne (PHI).
    Te klasy danych znacząco zwiększają ryzyko kradzieży tożsamości i nadużyć finansowych, a w przypadku PHI – długotrwałego narażenia prywatności.

Skala: 113 232 rekordów – liczba raportowana w komunikatach i powiązana z wpisem na portalu naruszeń HHS (OCR).

Praktyczne konsekwencje / ryzyko

  • Ryzyko finansowe: wykorzystanie SSN i danych kont do fraudów (kredyty, wnioski podatkowe, przejęcia kont).
  • Ryzyko prywatności: ujawnienie PHI może prowadzić do stygmatyzacji, szantażu i naruszenia poufności leczenia.
  • Ryzyko operacyjne: ransomware może powodować przestoje w systemach rejestracji, EHR i teleopieki, wpływając na ciągłość usług publicznych.

Rekomendacje operacyjne / co zrobić teraz

Dla osób poszkodowanych:

  1. Zamrożenie kredytu (credit freeze) w głównych biurach kredytowych oraz włączenie alertów oszustw.
  2. Monitorowanie kont bankowych i polis; skonfigurowanie powiadomień transakcyjnych.
  3. Weryfikacja wyciągów medycznych (Explanation of Benefits) pod kątem fikcyjnych świadczeń.
  4. Zmiana haseł/rotacja, włączenie MFA wszędzie, gdzie to możliwe.
  5. Zachowanie listów notyfikacyjnych i skorzystanie z oferowanego monitoringu tożsamości, jeśli zapewniono.

Dla organizacji zdrowotnych i JST (w tym RBHA i podobnych):

  • Segmentacja sieci oraz separacja systemów klinicznych od biurowych; wprowadzenie MFA + FIDO2 dla kont uprzywilejowanych.
  • Zarządzanie podatnościami: EDR/XDR z detekcją kradzieży danych (DLP), monitoring ruchu egress i blokady exfiltracji.
  • Kopia zapasowa 3-2-1 + testy odtwarzania; przechowywanie offline i immutable.
  • Plan IR zgodny z HIPAA Security Rule i NIST 800-61; przygotowane playbooki na double-extortion.
  • Zgodność i notyfikacje: raportowanie zgodnie z Va. Code § 32.1-127.1:05 (AG, Commissioner of Health, podmioty danych, rezydenci), dokumentacja działań naprawczych.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W ostatnich miesiącach odnotowano wiele incydentów w ochronie zdrowia (laboratoria, sieci klinik, dostawcy usług). Wspólny mianownik to ekfiltracja PHI i presja okupu. Przypadek RBHA wpisuje się w ten trend, łącząc kradzież danych z ransomware, ale wyróżnia się charakterem instytucji publicznej świadczącej usługi zdrowia psychicznego – co zwiększa wrażliwość wycieków i potencjalny impact społeczny.

Podsumowanie / kluczowe wnioski

  • Atak na RBHA to klasyczny scenariusz double-extortion: dostęp → exfiltracja → ransomware.
  • Ujawnione PHI + SSN + dane finansowe tworzą wysoki, długofalowy profil ryzyka dla obywateli.
  • Jednostki publiczne muszą wdrożyć kontrole „zero-trust”, silną segmentację, DLP i gotowość IR.
  • Z perspektywy compliance, kluczowe są sprawne notyfikacje zgodnie z prawem Wirginii i HIPAA oraz transparentna komunikacja z pacjentami.

Źródła / bibliografia

  • SecurityWeek: „113,000 Impacted by Data Breach at Virginia Mental Health Authority” – główne fakty o kradzieży danych i wdrożeniu ransomware. (SecurityWeek)
  • Comparitech: zgłoszenie 113 232 osób i kategorie danych, odniesienie do rejestru HHS. (Comparitech)
  • HIPAA Journal: oś czasu zdarzeń (~30 września 2025 r. wykrycie) i rekomendacje dla poszkodowanych. (hipaajournal.com)
  • Prawo Wirginii: Va. Code § 32.1-127.1:05 – Breach of medical information notification. (law.lis.virginia.gov)

React2Shell: krytyczna luka RCE w React Server Components (CVE-2025-55182) oraz duplikat w Next.js (CVE-2025-66478)

Wprowadzenie do problemu / definicja luki

3 grudnia 2025 r. zespół React ujawnił krytyczną podatność typu pre-auth RCE w protokole Flight dla React Server Components (RSC), śledzoną jako CVE-2025-55182 (CVSS 10.0). Dotyczy ona pakietu react-server i implementacji RSC w wersjach React 19.0–19.2.0 oraz bibliotekach react-server-dom-* (webpack/parcel/turbopack). Równolegle Next.js opublikował własne ogłoszenie (CVE-2025-66478), które następnie zostało odrzucone jako duplikat CVE-2025-55182.

W skrócie

  • Co to jest? Błąd nieserializowania bezpiecznego (unsafe deserialization) w obsłudze żądań Flight dla RSC prowadzący do zdalnego wykonania kodu bez uwierzytelnienia.
  • Kogo dotyczy? React 19 (pakiety react-server-dom-* w wersjach 19.0/19.1.0/19.1.1/19.2.0) oraz frameworki korzystające z RSC, m.in. Next.js 15.x/16.x (App Router).
  • Status Next.js: CVE-2025-66478 → duplikat CVE-2025-55182.
  • Wykryte nadużycia: CISA dodała CVE-2025-55182 do katalogu KEV (Known Exploited Vulnerabilities); Unit 42 opisuje realne działania poeksploatacyjne (skanowanie, web-shelle, kryptokoparki, próby Cobalt Strike).
  • Naprawa: aktualizacja do React 19.0.1 / 19.1.2 / 19.2.1 oraz do bieżących wersji Next.js z poprawkami.

Kontekst / historia / powiązania

Reakcja społeczności była natychmiastowa: oprócz oficjalnych biuletynów React i Next.js, w krótkim czasie pojawiły się alerty CISA oraz vendorów bezpieczeństwa. Vercel wydał podsumowanie i narzędzie ułatwiające podbicie projektów Next.js do wersji łatających błąd. 6 grudnia Vercel opublikował wpis z instrukcją i narzędziem npx fix-react2shell-next do automatycznej aktualizacji zależności w aplikacjach Next.js. 8 grudnia Unit 42 zaktualizowało swój raport, potwierdzając obserwacje działań atakujących.

Analiza techniczna / szczegóły luki

Rdzeń problemu: parser/warstwa deserializacji w RSC Flight akceptuje złośliwe, specjalnie spreparowane ładunki HTTP kierowane do Server Functions, co pozwala wpływać na logikę wykonania po stronie serwera i osiągnąć RCE. Co istotne, domyślna konfiguracja popularnych szablonów (np. świeżo utworzonego Next.js) była podatna bez modyfikacji kodu.

Zakres wersji:

  • React / RSC: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack w wersjach 19.0.0 / 19.1.0 / 19.1.1 / 19.2.0.
  • Next.js: głównie gałęzie 15.x i 16.x (App Router) oraz wybrane wydania canary od 14.3.0; projektowe domyślne wdrożenia były atakowalne.

Dlaczego to groźne dla „niewykorzystujących” Server Functions? Nawet jeśli aplikacja nie definiuje własnych endpointów Server Functions, obsługa RSC może być włączona „po drodze”, co utrzymuje powierzchnię ataku.

Praktyczne konsekwencje / ryzyko

  • Łatwość ataku: brak uwierzytelnienia, niski poziom złożoności, wysoka niezawodność exploita; podatność w konfiguracji domyślnej.
  • Skala: React/Next.js mają ogromny udział w rynku — CISA oznaczyła CVE jako znaną, wykorzystywaną; Unit 42 raportuje już poeksploatacyjne działania napastników (skrypty Bash, web-shelle, kryptokoparki, próby wdrożenia Cobalt Strike i aktywność IAB).
  • Potencjalny wpływ: przejęcie procesu serwerowego (Node.js), kradzież tajemnic (klucze, zmienne środowiskowe), pivot w sieci, trwale osadzone backdoory i dalsze kampanie (np. cryptojacking).

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowa aktualizacja (patch now):
    • React: do 19.0.1 / 19.1.2 / 19.2.1 (lub nowszych).
    • Next.js: do najnowszych wersji z poprawką; w projektach Next.js skorzystaj z narzędzia npx fix-react2shell-next (Vercel).
  2. Przegląd zależności: wymuś podbicie react, react-dom, react-server, react-server-dom-*, a w Next.js — aktualny next oraz bundlery (Turbopack/Webpack) w zgodnych wersjach. (Weryfikuj lockfile.)
  3. Twarde ograniczenia sieciowe: izoluj serwery renderujące (SSR/RSC), kontroluj wychodzące połączenia z Node.js (blokuj „curl/wget do Internetu”, egres tylko do potrzebnych usług). Obserwuj anomalie DNS/HTTP. (Wnioski z TTP napastników).
  4. Detekcja IOC/TTP: szukaj poleceń Base64 z potokami | base64 -d | sh, skryptów typu sex.sh, podejrzanych web-shelli „React File Manager”, prób pobrania C2, śladów Cobalt Strike/Mirai/NOODLERAT.
  5. Higiena sekretów: rotuj klucze/tokenty środowiskowe (CI/CD, .env), sprawdź uprawnienia ról w chmurze — traktuj serwer jako potencjalnie skompromitowany, jeśli był podatny i publicznie dostępny w okresie 3–8 grudnia 2025 r. (po ujawnieniu).
  6. Twardnienie buildów: włącz ograniczenia --frozen-lockfile, SCA w CI, testy E2E po aktualizacji; rozważ WAF z regułami blokującymi sekwencje Flight/RSC nietypowe dla twojej aplikacji. (Dodatkowe wskazówki społeczności).

Różnice / porównania z innymi przypadkami

  • Wzorzec błędu: klasyczne unsafe deserialization znane z ekosystemów Java/.NET teraz uderza w RSC/Node.js — wektor to niestandardowy protokół (Flight) i domyślna obsługa w popularnych frameworkach.
  • CVE w Next.js: początkowo wydzielone jako CVE-2025-66478, lecz scalone do Reactowego CVE-2025-55182 — z punktu widzenia ryzyka operacyjnego to jedna podatność w warstwie RSC.

Podsumowanie / kluczowe wnioski

  • To najpoważniejsza luka w ekosystemie React/Next.js od lat: CVSS 10.0, pre-auth RCE, domyślne konfiguracje atakowalne. Aktualizacje są dostępne — wdrażaj natychmiast.
  • Dowody nadużyć już istnieją (CISA KEV, telemetryczne obserwacje Unit 42). Reaguj jak na incydent: patch + poszukiwanie TTP/IOC + rotacja sekretów.

Źródła / bibliografia

  • React — Critical Security Vulnerability in React Server Components (03.12.2025). (React)
  • Next.js — Security Advisory: CVE-2025-66478 (06.12.2025). (Next.js)
  • NVD — CVE-2025-55182 (ostatnia aktualizacja ~3 dni temu). (nvd.nist.gov)
  • CISA — dodanie CVE-2025-55182 do KEV (05.12.2025). (CISA)
  • Unit 42 (Palo Alto Networks) — Exploitation of Critical Vulnerability in React Server Components (akt. 08.12.2025) — obserwacje skanowania i działań poeksploatacyjnych. (Unit 42)

Krytyczna podatność XXE w Apache Tika (CVE-2025-66516, CVSS 10.0) – co musisz załatać już teraz

Wprowadzenie do problemu / definicja luki

W Apache Tika ujawniono krytyczną lukę typu XML External Entity (XXE) oznaczoną jako CVE-2025-66516 z oceną CVSS 10.0. Błąd pozwala na XXE poprzez spreparowany plik XFA osadzony w PDF, co dotyka kluczowych modułów Tiki: tika-core, tika-pdf-module oraz tika-parsers. Projekt wskazuje, że usterka jest ściśle powiązana z wcześniejszym problemem (CVE-2025-54988), ale rozszerza zakres dotkniętych pakietów – dlatego wymaga pilnej aktualizacji nie tylko modułu PDF, lecz także rdzenia (tika-core).

W skrócie

  • Zakres podatnych pakietów:
    • org.apache.tika:tika-core 1.13 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parser-pdf-module 2.0.0 – 3.2.1 (naprawione w 3.2.2)
    • org.apache.tika:tika-parsers 1.13 – 1.28.5 (naprawione od 2.0.0 w górę)
  • Wektor ataku: XXE przez XFA w PDF, możliwy odczyt plików, SSRF, a w niektórych scenariuszach DoS.
  • Dlaczego nowe CVE? Poprzednie (CVE-2025-54988) skupiało się na module PDF; teraz potwierdzono, że problem i fix są w tika-core, a w gałęzi 1.x parser PDF znajdował się w tika-parsers. Użytkownicy, którzy zaktualizowali wyłącznie moduł PDF, wciąż mogli być podatni.
  • Pilne działanie: aktualizacja do Tika 3.2.2 (i odpowiednio do bezpiecznych wersji w gałęzi 2.x) oraz weryfikacja łańcuchów zależności.

Kontekst / historia / powiązania

W sierpniu 2025 ujawniono CVE-2025-54988 – XXE w parserze PDF Tiki. Część organizacji zaktualizowała jedynie moduł PDF, pozostawiając niezałatany tika-core, co utrzymywało okno podatności. Nowe CVE-2025-66516 formalizuje rozszerzony zakres i „zamyka” lukę poprzez wymaganie wersji tika-core ≥ 3.2.2. Dodatkowo w linii 1.x PDFParser był w pakiecie tika-parsers, więc także ten artefakt należy sprawdzić i zaktualizować.

Analiza techniczna / szczegóły luki

Atakujący osadza formularz XFA w dokumencie PDF. Podczas parsowania Tika – zależnie od ścieżki kodu i konfiguracji – może przetworzyć zewnętrzne encje XML (XXE), co umożliwia:

  • odczyt lokalnych plików (np. /etc/passwd, klucze, tokeny),
  • SSRF – wykonywanie żądań HTTP z serwera aplikacji do zasobów wewnętrznych (np. http://169.254.169.254/ w chmurze),
  • w niektórych przypadkach wyciek metadanych i zasobów lub wyczerpywanie zasobów (DoS).
    Problem jest w tika-core, a wejściem bywa moduł PDF; w gałęzi 1.x wejściem mógł być tika-parsers. To tłumaczy, czemu sama aktualizacja modułu PDF nie wystarcza.

Praktyczne konsekwencje / ryzyko

Tika jest powszechnie osadzana w wyszukiwarkach treści, e-discovery, DLP, systemach ETL, serwerach indeksujących, portalach do uploadu plików czy narzędziach bezpieczeństwa. Każda usługa, która przyjmuje PDF od użytkownika i przekazuje do Tiki, może stać się wektorem wycieku danych lub ruchu SSRF do sieci wewnętrznej i usług chmurowych. Instytucje rządowe ostrzegają przed eksfiltracją danych i rekonesansem wewnętrznej sieci przez tę lukę.

Rekomendacje operacyjne / co zrobić teraz

  1. Patch teraz
    • Upewnij się, że tika-core = 3.2.2 (lub nowszy), tika-parser-pdf-module = 3.2.2 (lub nowszy) oraz brak artefaktów 1.x (tika-parsers ≤ 1.28.5) w drzewie zależności. W ekosystemach Maven/Gradle wymuś wersje przez dependencyManagement/constraints.
  2. Przegląd transytywności
    • Audytuj aplikacje, które pośrednio wciągają Tikę (np. przez narzędzia wyszukiwania, DLP, CMS-y, biblioteki importu). Zadbaj o lockfile i raporty mvn dependency:tree/gradle dependencies. (Wnioski z doradców i ekosystemu GitHub Advisory.)
  3. Tymczasowe twardnienie (gdy aktualizacja wymaga okna serwisowego):
    • Odrzuć/izoluj PDF z XFA (np. wstępny „content sniffer” przed Tiką).
    • Sandbox dla procesu parsowania: AppArmor/SELinux, kontenery z restrykcyjnymi profilami, brak dostępu do metadanych chmury, brak sieci lub wyłącznie wyjście przez proxy/egress filter.
    • Limit zasobów (timeouty, limity pamięci/CPU) na pipeline’ach parsowania.
  4. Detekcja i reagowanie
    • Szukaj anomalii: żądania do IMDS (169.254.169.254), nietypowe odczyty plików przez usługę parsującą, nadmiarowe błędy parsera PDF.
    • Dodaj reguły w WAF/IDS (sygnatury PDF z XFA, nietypowe nagłówki/URI).
  5. Testy bezpieczeństwa
    • Przeprowadź testy jednostkowe/integracyjne z próbkami PDF zawierającymi XFA, aby potwierdzić, że aplikacja nie przetwarza zewnętrznych encji po aktualizacji.

Różnice / porównania z innymi przypadkami

  • CVE-2025-54988 vs. CVE-2025-66516: w obu przypadkach wektorem jest XFA w PDF, ale 66516 formalnie poszerza listę podatnych pakietów i wskazuje, że rdzeń (tika-core) zawierał przyczynę – stąd wymóg jego aktualizacji do ≥ 3.2.2. Jeśli załatano tylko moduł PDF, system nadal mógł być podatny.

Podsumowanie / kluczowe wnioski

  • To krytyczna luka (CVSS 10.0) w popularnym komponencie przetwarzania dokumentów.
  • Aktualizacja tika-core do 3.2.2 (oraz modułów PDF) jest warunkiem koniecznym.
  • Przejrzyj wszystkie aplikacje z PDF upload/parsing oraz zależności transytywne – Tika bywa ukryta w wielu platformach.
  • Dodaj kontrole prewencyjne (filtrowanie XFA, sandbox, egress filtering) i monitoring pod kątem SSRF/wycieków.

Źródła / bibliografia

  • The Hacker News – pierwsza publikacja prasowa i zestawienie wersji dotkniętych/naprawionych. (The Hacker News)
  • NVD (NIST) – karta CVE-2025-66516 z oceną CVSS i opisem rozszerzenia zakresu względem CVE-2025-54988. (NVD)
  • GitHub Advisory (GHSA-f58c-gq56-vjjf) – szczegóły: przyczyna w tika-core, konsekwencje „partial patch”, wersje naprawione. (GitHub)
  • Belgian CCB (rządowe CERT) – ostrzeżenie o eksfiltracji danych/SSRF i szerokim użyciu Tiki. (ccb.belgium.be)
  • Strona projektu Apache Tika – ogólne info o wydaniach i bezpieczeństwie (w tym 3.2.2 jako najnowsza linia 3.x). (tika.apache.org)