Archiwa: NIST - Strona 24 z 38 - Security Bez Tabu

Tag: NIST

Publiczny exploit na krytyczną lukę w FortiSIEM: zdalne RCE bez uwierzytelnienia i droga do roota (CVE-2025-64155)

Wprowadzenie do problemu / definicja luki

Fortinet FortiSIEM (SIEM/UEBA) dostał krytyczną podatność umożliwiającą zdalne wykonanie poleceń/kodu bez uwierzytelnienia w wyniku błędnej neutralizacji elementów w wywołaniu komendy systemowej (CWE-78). Luka jest śledzona jako CVE-2025-64155 i – co najważniejsze operacyjnie – ma już upubliczniony PoC/exploit, co zwykle znacząco przyspiesza adopcję przez atakujących.

Uwaga porządkująca nazewnictwo: część publikacji nagłośniła temat pod wcześniejszym identyfikatorem CVE-2025-25256 (sierpień 2025). Badacze opisują jednak, że dalsza analiza doprowadziła do odkrycia nowej, łańcuchowej podatności i przypisania jej CVE-2025-64155.

W skrócie

  • Co to jest: zdalna, nieuwierzytelniona podatność prowadząca do RCE i w typowym scenariuszu do pełnej kompromitacji (root).
  • Gdzie: FortiSIEM – problem dotyczy usług komunikacyjnych phMonitor (wskazywany port TCP/7900 jako kluczowy punkt ekspozycji/mitigacji).
  • Wersje podatne (przykładowe zakresy): 6.7.0–6.7.10, 7.0.0–7.0.4, 7.1.0–7.1.8, 7.2.0–7.2.6, 7.3.0–7.3.4 oraz 7.4.0.
  • Status eksploitu: PoC opublikowany, brak potwierdzonych raportów o masowym „in-the-wild” w momencie publikacji analiz (ale ryzyko gwałtownie rośnie).
  • Najważniejsze działanie: patch/upgrade + natychmiastowe odcięcie dostępu do TCP/7900 z sieci niezaufanych.

Kontekst / historia / powiązania

Badacze z Horizon3.ai wskazują, że phMonitor był już historycznie „wejściem” do kilku podatności w FortiSIEM (wspominane m.in. CVE-2023-34992 i CVE-2024-23108), a zainteresowanie podatnościami Fortinetu bywa wysokie także po stronie grup ransomware (w kontekście FortiSIEM przywołano wątek zainteresowania w wyciekach czatów).

W praktyce to klasyczny wzorzec: produkt infrastrukturalny (SIEM) często stoi wysoko w zaufaniu sieciowym, a kiedy pojawia się RCE bez auth + PoC, czas do prób skanowania/ataku w internecie zwykle skraca się do godzin–dni.

Analiza techniczna / szczegóły luki

Z perspektywy technicznej, opis Horizon3.ai jest szczególnie istotny, bo pokazuje nie tylko „command injection”, ale łańcuch prowadzący do roota:

  1. Brak uwierzytelnienia do handlerów w phMonitor
    phMonitor mapuje dziesiątki handlerów operacji (komendy/typy żądań) i – kluczowo – część z nich jest dostępna zdalnie bez autoryzacji.
  2. Wejście przez obsługę żądania storage typu elastic
    W określonym przepływie parametry z payloadu (XML) trafiają do skryptu elastic_test_url.sh jako argumenty. Wprowadzono warstwę „utwardzania” (np. owijanie argumentów w cudzysłowy), ale…
  3. Argument injection do curl zamiast klasycznego command injection
    Skrypt buduje komendę curl, a następnie ją wykonuje. Badacze pokazują, że da się „wstrzyknąć” dodatkowe argumenty curl (np. zapis do pliku) – finalnie wykorzystując funkcję --next, która pozwala łańcuchować żądania w jednej instancji curl. To omija część ochrony wynikającej z cytowania argumentów.
  4. Arbitrary file write jako użytkownik uprzywilejowany (admin), a potem eskalacja do roota
    W demonstracji plik wykonywalny cyklicznie uruchamiany w systemie jest nadpisywany, co daje shell jako „admin”, a następnie wykorzystywany jest fakt, że pewne pliki wykonywane przez root są zapisywalne przez admin (np. skrypt uruchamiany z crona), co prowadzi do root.

Dodatkowo BleepingComputer zwraca uwagę na praktyczny trop detekcyjny: w logach phMonitor (/opt/phoenix/log/phoenix.logs) warto szukać wpisów zawierających m.in. PHL_ERROR i wskazania URL payloadu oraz docelowej ścieżki zapisu.

Praktyczne konsekwencje / ryzyko

Dlaczego to „pali się” bardziej niż typowa podatność?

  • Brak uwierzytelnienia + zdalny wektor sieciowy → niski próg ataku, szybka automatyzacja skanami.
  • PoC publicznie dostępny → rośnie prawdopodobieństwo masowych prób, nawet jeśli wcześniej brak było obserwacji „in-the-wild”.
  • FortiSIEM jako „high-trust asset”: kompromitacja SIEM to nie tylko RCE na serwerze – to często dostęp do integracji, kluczy, tokenów, poświadczeń do kolektorów i systemów logowania, a także idealny punkt do ruchu bocznego.

Rekomendacje operacyjne / co zrobić teraz

1) Patch/upgrade – priorytet P1

Zgodnie z dostępnymi zestawieniami wersji naprawionych:

  • 7.4: aktualizuj do 7.4.1+
  • 7.3: do 7.3.5+
  • 7.2: do 7.2.7+
  • 7.1: do 7.1.9+
  • Linie 6.7 i 7.0: rekomendowana migracja do wspieranej, naprawionej wersji (zamiast oczekiwania na łatkę).

2) Ogranicz ekspozycję phMonitor (TCP/7900) – natychmiast

Jeśli nie możesz zapatchować od razu, wdrożenie kontroli dostępu do portu 7900 (tylko z zaufanych segmentów/hostów) jest wskazywane jako workaround.

Minimalny baseline:

  • zablokuj TCP/7900 z Internetu i sieci użytkowników,
  • dopuść wyłącznie komunikację wymaganą topologią (kolektory ↔ supervisor),
  • dodaj alerty na nietypowe źródła ruchu do 7900.

3) Detekcja i triage

  • Przeszukaj logi: /opt/phoenix/log/phoenix.logs pod kątem anomalii i wzorców typu PHL_ERROR oraz podejrzanych ścieżek zapisu.
  • Sprawdź integralność/zmiany w lokalizacjach wskazywanych w analizie (przykładowo pliki nadpisywane w scenariuszu PoC) i wykonaj szybki hunting pod kątem „nagle zmienionych” plików wykonywalnych/skryptów.

4) Po incydencie lub podejrzeniu kompromitacji

  • rotacja kluczy/poświadczeń dostępnych z FortiSIEM (integracje, konta serwisowe, tokeny),
  • przegląd połączeń wychodzących (reverse shell / nietypowe egress),
  • weryfikacja cronów i plików uruchamianych cyklicznie.

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

Warto zwrócić uwagę na różnicę jakościową: wiele błędów klasy „OS command injection” to pojedynczy punkt wstrzyknięcia. Tutaj badacze opisują argument injection do curl + arbitralny zapis pliku + eskalację przez błędne uprawnienia plików wykonywanych przez roota. To podejście jest szczególnie „produkcyjne” dla atakujących, bo:

  • pozwala obejść część utwardzeń (cytowanie argumentów),
  • daje stabilny prymityw (write-what-where w granicach uprawnień),
  • łatwo przerobić na trwałość (persistencję) przez pliki wykonywane cyklicznie.

Podsumowanie / kluczowe wnioski

  • CVE-2025-64155 to krytyczna podatność FortiSIEM umożliwiająca unauth RCE i typowo root w wyniku łańcucha błędów/konfiguracji.
  • Publiczny exploit/PoC znacząco zwiększa presję na szybkie działania obronne.
  • Najważniejsze kroki: aktualizacja do wersji naprawionych + odcięcie/ograniczenie TCP/7900 + szybki hunting w logach phMonitor.

Źródła / bibliografia

  1. BleepingComputer – informacja o upublicznieniu exploitu/PoC, mitigacji (port 7900) i wskazówkach dot. logów. (BleepingComputer)
  2. Horizon3.ai – techniczny write-up łańcucha: phMonitor → elastic_test_url.sh → argument injection do curl → zapis pliku → eskalacja do roota. (Horizon3.ai)
  3. Tenable – podsumowanie ryzyka, kontekst oraz tabela wersji podatnych/naprawionych. (Tenable®)
  4. NVD (NIST) – opis CVE i zakresy podatnych wersji. (NVD)

Palo Alto Networks ostrzega: luka DoS w PAN-OS (CVE-2026-0227) może „wyłączyć” firewalle przez tryb maintenance

Wprowadzenie do problemu / definicja luki

Palo Alto Networks opublikowało ostrzeżenie dotyczące podatności CVE-2026-0227 w systemie PAN-OS, która pozwala niezautoryzowanemu atakującemu doprowadzić do odmowy usługi (DoS) na firewallu. Kluczowy szczegół: wielokrotne wywołanie błędu może przełączyć urządzenie w tryb maintenance mode, co w praktyce oznacza utratę ochrony realizowanej przez firewall do czasu ręcznego odtworzenia działania.

W skrócie

  • Co: DoS w GlobalProtect Gateway/Portal (PAN-OS / Prisma Access), skutkujący przejściem firewalla w maintenance mode po powtarzaniu ataku.
  • Kto może zaatakować: atak bez uwierzytelnienia, z sieci (AV:N), bez interakcji użytkownika.
  • Wpływ: przede wszystkim dostępność (Availability = High), ryzyko przerwy w łączności i „wyłączenia” egzekwowania polityk.
  • Ocena: CVSS-BT 7.7 (HIGH); Palo Alto oznacza Exploit Maturity: PoC.
  • Status eksploatacji: producent deklaruje, że nie ma wiedzy o złośliwej eksploatacji w momencie publikacji.
  • Działanie naprawcze: aktualizacja do wydań wskazanych przez producenta (patrz sekcja rekomendacji).

Kontekst / historia / powiązania

GlobalProtect to jeden z najczęściej wystawianych na internet komponentów ekosystemu Palo Alto (VPN/remote access), więc jest naturalnym celem kampanii zarówno na podatności, jak i na brute force. Media branżowe zwracają uwagę na to, że powierzchnia ataku firewalli/VPN-ów stale przyciąga napastników, bo skuteczny incydent na brzegu sieci daje efekt „domina” dla reszty organizacji.

Warto też pamiętać, że „maintenance mode po powtarzaniu DoS” to wzorzec, który pojawiał się już w innych lukach PAN-OS (np. historyczne przypadki DoS prowadzące do rebootów i maintenance mode).

Analiza techniczna / szczegóły luki

Z komunikatu PSIRT Palo Alto wynika, że:

  • podatność dotyczy PAN-OS oraz Prisma Access wyłącznie w konfiguracjach z włączonym GlobalProtect gateway lub portal (warunek ekspozycji),
  • atak jest zdalny i bez uwierzytelnienia, a powtarzanie wywołania błędu może doprowadzić do maintenance mode wymagającego interwencji użytkownika/administratora,
  • klasyfikacja słabości to CWE-754 (Improper Check for Unusual or Exceptional Conditions).

Wersje/linie i poprawki (wycinek najważniejszych):

  • PAN-OS 12.1: aktualizacja do 12.1.4 lub nowszej,
  • PAN-OS 11.2: do 11.2.10-h2 lub nowszej (alternatywnie gałęzie pośrednie wg tabeli producenta),
  • PAN-OS 11.1: do 11.1.13 lub nowszej,
  • PAN-OS 10.2: do wersji „fixed” wskazanych przez Palo Alto (np. 10.2.18-h1 i inne poprawione buildy),
  • PAN-OS 10.1: do 10.1.14-h20 lub nowszej,
  • Prisma Access: poprawione buildy dla gałęzi 10.2 i 11.2 są dostępne; Palo Alto informuje, że większość instancji w chmurze została już zaktualizowana, a reszta jest doschedulowana.

Dodatkowy niuans operacyjny: mimo że advisory odsyła do NVD, w momencie sprawdzania wpis może nie być jeszcze dostępny w bazie (NVD potrafi mieć opóźnienia / statusy „not found”).

Praktyczne konsekwencje / ryzyko

Największe ryzyko jest „nudne, ale bolesne”: utrata dostępności brzegowej kontroli ruchu i potencjalna przerwa w zdalnym dostępie (VPN) lub publikowanych usługach, jeśli urządzenie pełni krytyczną rolę na styku. Przy przejściu w maintenance mode organizacja może zostać zmuszona do:

  • ręcznego przywracania działania,
  • przełączeń awaryjnych (HA/failover),
  • odtwarzania usług z pominięciem standardowych ścieżek kontroli bezpieczeństwa.

W praktyce atak DoS na firewall bywa też „zasłoną dymną”: w czasie, gdy zespół walczy z przywróceniem dostępu, rośnie okno na inne działania (phishing, próby przejęć kont, skanowanie). To nie wynika wprost z advisory, ale jest typowym scenariuszem operacyjnym przy incydentach na brzegu.

Rekomendacje operacyjne / co zrobić teraz

  1. Zidentyfikuj ekspozycję
  • Sprawdź, czy masz włączony GlobalProtect gateway/portal na instancjach PAN-OS/Prisma Access (to warunek podatności).
  1. Patchuj priorytetowo (najlepiej w trybie change “hot”)
  • Zaktualizuj do wersji wskazanych przez producenta dla Twojej gałęzi (12.1 / 11.2 / 11.1 / 10.2 / 10.1).
  1. Jeśli patch nie może wejść natychmiast (kompensacja ryzyka)
    Producent wskazuje brak „workaroundu” w sensie eliminacji podatności, ale możesz ograniczać ryzyko operacyjnie:
  • ogranicz ekspozycję GlobalProtect (np. allowlist adresów źródłowych do portalu/gateway, segmentacja dostępu),
  • włącz/zweryfikuj rate limiting / DDoS protection przed usługą (tam gdzie to możliwe),
  • wzmocnij monitoring pod kątem symptomów DoS i restartów/maintenance mode (alerty z logów, korelacje).
  1. Przygotuj plan „recovery”
  • upewnij się, że masz procedurę powrotu z maintenance mode (dostęp out-of-band, uprawnienia, okna serwisowe),
  • sprawdź HA: czy failover nie przeniesie problemu na drugą jednostkę przy ataku na oba węzły.

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

  • CVE-2026-0227 dotyczy ścieżki GlobalProtect (gateway/portal) i wymaga konkretnej konfiguracji ekspozycji.
  • Dla kontrastu, historyczne DoS-y PAN-OS bywały związane np. z innymi funkcjami dataplane (np. DNS Security logging w CVE-2024-3393), ale efekt operacyjny mógł wyglądać podobnie: reboot/maintenance mode po powtarzaniu wyzwalacza.

Podsumowanie / kluczowe wnioski

  • To podatność DoS o wysokiej istotności (CVSS-BT 7.7), która może wyłączyć egzekwowanie ochrony przez przełączenie firewalla w maintenance mode po powtarzaniu ataku.
  • Ryzyko jest najwyższe tam, gdzie GlobalProtect jest wystawiony do internetu i krytyczny dla ciągłości działania (zdalny dostęp, dostęp do aplikacji).
  • Najlepsza odpowiedź jest prosta: aktualizacja do wskazanych buildów + wzmocnienie monitoringu i gotowości recovery.

Źródła / bibliografia

  1. Palo Alto Networks PSIRT Advisory: CVE-2026-0227 – PAN-OS: Firewall DoS in GlobalProtect Gateway and Portal. (security.paloaltonetworks.com)
  2. BleepingComputer: Palo Alto Networks warns of DoS bug letting hackers disable firewalls (15 stycznia 2026). (BleepingComputer)
  3. The Hacker News: Palo Alto Fixes GlobalProtect DoS Flaw That Can Crash Firewalls Without Login (15 stycznia 2026). (The Hacker News)
  4. TechRadar Pro: Palo Alto patches a worrying security issue… (15 stycznia 2026). (TechRadar)
  5. NIST NVD: informacja o braku wpisu dla CVE-2026-0227 w momencie sprawdzania. (NVD)

UAT-8837: chińsko-powiązany aktor APT poluje na dostęp początkowy w sektorach infrastruktury krytycznej w Ameryce Północnej

Wprowadzenie do problemu / definicja luki

Cisco Talos opisuje UAT-8837 jako aktora APT o średnim poziomie pewności powiązań z Chinami, którego główną rolą wydaje się być pozyskiwanie dostępu początkowego (initial access) do organizacji o wysokiej wartości — a niekoniecznie prowadzenie pełnej kampanii destrukcyjnej czy ransomware. To ważne rozróżnienie: initial-access skupia się na wejściu, rozpoznaniu, kradzieży poświadczeń i „poręczach” do ponownych wejść, często przygotowując grunt pod kolejne etapy działań (także innych zespołów).

W tle pojawia się też wątek eksploatacji podatności CVE-2025-53690 (Sitecore, deserializacja ViewState), co sugeruje dostęp do świeżych technik/łańcuchów eksploatacyjnych i sprawność w szybkim monetyzowaniu błędów w systemach publicznie wystawionych.

W skrócie

  • Kto? UAT-8837 — Talos: medium confidence China-nexus APT.
  • Kogo atakuje? Od co najmniej 2025 r. wyraźny fokus na organizacjach z obszaru infrastruktury krytycznej w Ameryce Północnej.
  • Jak wchodzi? Eksploatacja podatnych serwerów (n-day i zero-day) oraz użycie przejętych poświadczeń.
  • Co robi po wejściu? Recon + kradzież informacji o domenie/AD + budowa wielu kanałów dostępu, głównie narzędziami open-source (Earthworm, SharpHound, DWAgent, Certipy itd.).
  • Detekcja/coverage: Talos podaje m.in. sygnaturę ClamAV (Win.Malware.Earthworm) i zestaw SID-ów Snort.
  • IOC: Talos publikuje hashe narzędzi oraz adresy IP infrastruktury (przykłady niżej).

Kontekst / historia / powiązania

Talos wskazuje na nakładanie się TTP UAT-8837 z innymi grupami z „chińskiego ekosystemu” (China-nexus), ale jednocześnie zaznacza medium confidence — co w praktyce oznacza: są przesłanki behawioralne i operacyjne, jednak atrybucja nie jest przedstawiona jako „zamknięta”.

Warto też zauważyć, że CVE-2025-53690 ma dobrze udokumentowany kontekst operacyjny: w analizie Google Cloud/Mandiant opisano realne nadużycia ViewState prowadzące do RCE w określonych wdrożeniach Sitecore (m.in. przypadki użycia przykładowego machine key z historycznych guide’ów).

Analiza techniczna / szczegóły luki

Wejście: podatności + konta

Talos opisuje dwa dominujące wektory initial access:

  1. Eksploatacja serwerów (w tym przypadek CVE-2025-53690).
  2. Użycie skompromitowanych poświadczeń.

Wczesny recon i „hands-on-keyboard”

Po uzyskaniu przyczółka operatorzy wykonują klasyczny zestaw komend rozpoznawczych (procesy, połączenia, użytkownicy, host, sesje) i przechodzą do działań interaktywnych na hoście (cmd.exe).

Istotny detal: Talos widzi wyłączanie mechanizmu RestrictedAdmin dla RDP poprzez modyfikację rejestru (po to, by ułatwić pozyskanie/wykorzystanie poświadczeń przy zdalnym dostępie).

Staging: gdzie lądują narzędzia

Talos wskazuje katalogi intensywnie wykorzystywane do „magazynowania” artefaktów:

  • C:\Users\<user>\Desktop\
  • C:\Windows\Temp\
  • C:\Windows\Public\Music

Toolchain: narzędzia i ich rola

UAT-8837 bazuje w dużym stopniu na narzędziach publicznych i miesza warianty, gdy są blokowane przez EDR/EPP (Talos wprost sugeruje „cycling” wersji narzędzi).

Najważniejsze elementy łańcucha po kompromitacji (wg Talos):

  • GoTokenTheft – kradzież tokenów dostępu i wykonywanie działań z podniesionymi uprawnieniami (Talos opisuje lokalizację i kontekst użycia).
  • Earthworm – tunelowanie/ruch typu reverse tunnel, wystawianie zasobów wewnętrznych na infrastrukturę atakującego (Talos podaje przykładowe komendy reverse socks/tunnel).
  • DWAgent – zdalna administracja, utrzymanie dostępu i „dropowanie” kolejnych elementów.
  • SharpHound + Certipy – rozpoznanie AD i elementy nadużyć wokół AD/PKI.
  • Impacket / Invoke-WMIExec / GoExec – próby zdalnego wykonania i lateral movement (w tym WMI/DCOM).
  • Rubeus – zestaw narzędzi do nadużyć Kerberos.

Recon domeny i AD

Talos pokazuje zestawy komend typu net group, nltest, setspn, a także wykorzystanie dsquery/dsget do masowego wyciągania atrybutów użytkowników i kont serwisowych — to klasyczny etap przygotowania do eskalacji uprawnień oraz polowania na „bogate” konta.

Utrzymanie dostępu: konta-tylne-furtki

Wprost opisano tworzenie kont domenowych (lub dodawanie istniejących kont do grup) jako kolejnego kanału powrotu do środowiska.

Sygnalizowany wątek supply chain

Talos odnotowuje przypadek eksfiltracji bibliotek DLL powiązanych z produktami ofiary, sugerując ryzyko przyszłego „trojanizowania” lub reverse engineeringu pod kątem kolejnych podatności — to szczególnie niepokojące w kontekście dostawców dla infrastruktury krytycznej.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko trwałej obecności: DWAgent + nowe konta + tunele to przepis na wiele niezależnych ścieżek powrotu.
  2. Ryzyko eskalacji domenowej: recon AD (SharpHound/Certipy/Rubeus) często poprzedza przejęcie kluczowych tożsamości i kontrolę nad środowiskiem.
  3. Ryzyko lateral movement: WMI/DCOM i RDP (wspierane zmianami w rejestrze) zwiększają zasięg intruza.
  4. Ryzyko dla systemów wystawionych do Internetu: CVE-2025-53690 dotyczy Sitecore i została opisana jako podatność typu deserializacja niezaufanych danych prowadząca do code injection; NVD wskazuje też, że CVE znalazło się w katalogu KEV CISA.
  5. Ryzyko łańcucha dostaw / własności intelektualnej: eksfiltracja DLL może zwiastować kolejne kampanie (np. „podmiana” komponentów lub szukanie błędów w produktach).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: ogranicz initial access

  • Zidentyfikuj internet-facing systemy (szczególnie CMS/aplikacje web) i porównaj z podatnościami/konfiguracjami ryzykownymi (dla Sitecore: wątek ViewState/machine key i zalecenia producenta/analizy Mandiant).
  • Wymuś higienę tożsamości: MFA wszędzie, gdzie to możliwe; rotacja haseł uprzywilejowanych; detekcja anomalii logowania i „impossible travel”.

Priorytet 2: polowanie na zachowania i artefakty (TTP > IOC)

  • Monitoruj modyfikacje klucza rejestru dot. DisableRestrictedAdmin (zmiany pod RDP) oraz nietypowe uruchomienia cmd.exe/narzędzi administracyjnych na serwerach aplikacyjnych.
  • Kontrola staging paths: alarmuj na nowe binaria/skrypty w C:\Windows\Temp\ i C:\Windows\Public\Music, zwłaszcza gdy pliki udają .ico/.txt, a w praktyce są wykonywalne.
  • AD hunting: wykrywanie masowego dsquery/dsget, setspn -Q */*, nietypowych zapytań o membershipy i atrybuty kont serwisowych.
  • Account governance: alertuj na net user ... /add /domain, dodawanie kont do lokalnych grup administracyjnych i zmiany w grupach domenowych.

Priorytet 3: detekcje sieciowe i endpointowe

  • Jeśli używasz Snort, zweryfikuj wdrożenie wskazanych SID-ów (Snort 2 i Snort 3) oraz aktualność feedów.
  • Dla AV/anty-malware: Talos wskazuje sygnaturę ClamAV Win.Malware.Earthworm.

Priorytet 4: szybkie sprawdzenie IOC (punkt startowy)

Talos publikuje m.in. hashe i IP powiązane z aktywnością. Przykładowe elementy do natychmiastowego „sweepu”:

  • IP: 74[.]176[.]166[.]174, 20[.]200[.]129[.]75, 172[.]188[.]162[.]183, 4[.]144[.]1[.]47, 103[.]235[.]46[.]102
  • SHA-256 (wybrane):
    • 1b3856e5d8c6a4cec1c09a68e0f87a5319c1bd4c8726586fd3ea1b3434e22dfa (GoTokenTheft)
    • 451e03c6a783f90ec72e6eab744ebd11f2bdc66550d9a6e72c0ac48439d774cd (Earthworm)
    • 5090f311b37309767fb41fa9839d2770ab382326f38bab8c976b83ec727e6796 (SharpHound)
    • 887817fbaf137955897d62302c5d6a46d6b36cb34775e4693e30e32609fb6744 (GoExec)

Uwaga praktyczna: IOC traktuj jako „wskazówkę”, a nie wyrocznię — kluczowe jest wykrywanie zachowań (tunelowanie, recon AD, tworzenie kont, staging w publicznych katalogach), bo UAT-8837 ma obserwowaną skłonność do rotowania narzędzi.

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

  • Model działania „initial access-first” jest charakterystyczny dla kampanii, które chcą utrzymać długoterminowy dostęp i opcjonalnie przekazać „wejście” dalej (wewnętrznie lub zewnętrznie), zamiast od razu wdrażać destrukcję. W materiale Talos to mocno wybrzmiewa: narzędzia, recon, AD, wiele kanałów dostępu.
  • Wysoka adaptacyjność narzędziowa (cycling wariantów pod EDR) to element, który w praktyce obniża skuteczność statycznych blokad hash/opis i podnosi znaczenie telemetrii behawioralnej.
  • CVE-2025-53690 wyróżnia się tym, że doczekało się szczegółowego opisu łańcucha ataku (ViewState, machine key, RCE) oraz zostało ujęte w NVD wraz z informacją o obecności w KEV CISA — co w wielu organizacjach powinno automatycznie windować priorytet patch/mitigation.

Podsumowanie / kluczowe wnioski

UAT-8837 to przykład aktora, który systematyzuje wejście i utrzymanie dostępu, a po kompromitacji szybko przechodzi do rekonesansu i „porządkowania” Active Directory pod dalsze operacje. Jeśli Twoja organizacja ma elementy łańcucha dostaw dla infrastruktury krytycznej (lub sama do niej należy), ten profil działań jest szczególnie ryzykowny: już sama kradzież konfiguracji, poświadczeń i komponentów (np. DLL) może stworzyć warunki pod kolejne fale ataków.

Najbardziej opłacalne działania obronne to: twarde ograniczenie initial access (patch + redukcja powierzchni + tożsamość), detekcja zachowań w AD i na serwerach, oraz szybkie „sweepy” IOC jako wsparcie, nie fundament strategii.

Źródła / bibliografia

  1. Cisco Talos: UAT-8837 targets critical infrastructure sectors in North America (15 stycznia 2026). (Cisco Talos Blog)
  2. Google Cloud / Mandiant: ViewState Deserialization Zero-Day Vulnerability in Sitecore Products (CVE-2025-53690) (3 września 2025). (Google Cloud)
  3. NIST NVD: CVE-2025-53690 Detail (publikacja 3 września 2025; KEV CISA odnotowane na stronie CVE). (NVD)
  4. Materiał referencyjny nt. sektorów infrastruktury krytycznej (16 sektorów, PPD-21) — kopia treści CISA w formie PDF. (cdn.lawreportgroup.com)

JPMorgan ujawnia wyciek danych inwestorów po incydencie w kancelarii Fried Frank – sygnał alarmowy dla ryzyka stron trzecich

Wprowadzenie do problemu / definicja luki

Incydenty u dostawców i partnerów (third-party / supply-chain) od lat są jedną z najtrudniejszych klas zdarzeń bezpieczeństwa: organizacja „A” może mieć dobre kontrole, ale dane i procesy i tak „wypływają” do organizacji „B” (np. kancelarii, audytora, operatora transferu plików). Kancelarie prawne to szczególnie wrażliwy węzeł – przechowują dokumenty transakcyjne, listy inwestorów, dane identyfikacyjne i korespondencję, często w jednym miejscu i w formie gotowej do nadużyć.

W skrócie

  • JPMorgan Chase poinformował część inwestorów o naruszeniu danych wynikającym z incydentu u zewnętrznej kancelarii Fried, Frank, Harris, Shriver & Jacobson LLP.
  • Według treści notyfikacji „nieuprawniona osoba trzecia” skopiowała pliki z współdzielonego dysku sieciowego kancelarii.
  • Ujawnione dane obejmują m.in. imiona i nazwiska, dane kontaktowe, numery rachunków, SSN oraz numery paszportów / innych dokumentów rządowych.
  • JPMorgan wskazał, że dotyczy to 659 osób (inwestorów funduszu private equity) i że systemy banku nie zostały naruszone.
  • Ten sam incydent był wcześniej łączony z ujawnieniami dotyczącymi Goldman Sachs (grudzień 2025).
  • Wątek ma też wymiar prawny: kancelaria mierzy się z pozwami związanymi z ochroną danych.

Kontekst / historia / powiązania

SecurityWeek opisał sprawę 13 stycznia 2026 r., wskazując na wspólny mianownik: ten sam incydent w Fried Frank skutkował komunikacją do inwestorów zarówno po stronie JPMorgan, jak i wcześniej Goldmana.
Bloomberg informował 24 grudnia 2025 r., że Goldman ostrzegł inwestorów, iż ich dane mogły zostać ujawnione w wyniku naruszenia u „jednej z kancelarii” – wprost wskazując Fried Frank.

Bloomberg Law opisywał następnie pozew dotyczący zarzutów niewystarczającej ochrony danych i ryzyka długotrwałych skutków dla poszkodowanych.

Analiza techniczna / szczegóły luki

Najważniejszy techniczny trop z ujawnień to sformułowanie, że atakujący „skopiował pliki z współdzielonego dysku sieciowego” (shared network drive).

W praktyce taki opis najczęściej oznacza jeden z poniższych scenariuszy (albo ich kombinację):

  1. Kompromitacja konta i dostępu do zasobu plikowego
    • kradzież poświadczeń (phishing, credential stuffing, malware),
    • ominięcie MFA (np. through token theft / session hijack),
    • nadużycie uprawnień nadanych zbyt szeroko (brak least privilege).
  2. Dostęp lateralny po wejściu do sieci kancelarii
    Po uzyskaniu przyczółka (VPN/VDI/endpoint) atakujący szuka udziałów SMB/NFS, indeksuje katalogi i wykonuje masowe kopiowanie (często z automatyzacją i kompresją).
  3. „Ciche” wyprowadzenie danych bez szyfrowania (bez klasycznego ransomware)
    Wyciek z udziału sieciowego bywa realizowany bez widocznego szyfrowania – co utrudnia wczesne wykrycie, jeśli nie ma DLP, monitoringu anomalii transferu i sensownej telemetrii.

SecurityWeek podkreśla, że nie wskazano sprawcy, nie widać też publicznego przyznania się grup ransomware; autor dopuszcza jednak wariant, że mogło dojść do zdarzenia ransomware (np. z zapłatą okupu) – ale to pozostaje spekulacją na bazie ograniczonych informacji.

Praktyczne konsekwencje / ryzyko

Zakres ujawnionych danych (PII + identyfikatory rządowe + numery rachunków) jest „wysokowartościowy”, bo umożliwia nie tylko phishing, ale też wielokanałowe nadużycia:

  • Spear-phishing / BEC podszywający się pod bank, fundusz lub kancelarię (dane pasują do narracji i zwiększają wiarygodność).
  • Próby przejęcia kont / procesów KYC (PII + dokumenty) – szczególnie tam, gdzie procesy obsługi inwestorów dopuszczają „odzyskanie dostępu” na podstawie danych osobowych.
  • Fraud finansowy: zmiany danych do wypłat, fałszywe dyspozycje, social engineering na infoliniach.
  • Długofalowe ryzyko tożsamościowe – w pozwie opisywanym przez Bloomberg Law pada teza o potencjalnie wieloletnich skutkach dla poszkodowanych.

Rekomendacje operacyjne / co zrobić teraz

Dla organizacji (bank/fundusz) dotkniętej incydentem strony trzeciej

  1. TPRM „na serio” (Third-Party Risk Management)
    • twarde wymagania dot. MFA, EDR, logowania dostępu do udziałów plikowych, segmentacji i szyfrowania,
    • audyt uprawnień do danych klientów/inwestorów i zasada minimalizacji.
  2. Kontrole danych, nie tylko dostawcy
    • klasyfikacja danych i ograniczanie „wypływu” PII do kancelarii do absolutnego minimum,
    • DLP / CASB dla kanałów wymiany dokumentów, znakowanie i monitoring masowych eksportów.
  3. Wymogi kontraktowe i „right to verify”
    • SLA na czas powiadomienia o incydencie, obowiązek dostarczenia ustaleń (w zakresie możliwym prawnie),
    • możliwość weryfikacji remediacji (np. testy, attestation, raport z audytu).
  4. Przygotowana komunikacja i procedury
    FTC wprost rekomenduje szybkie uruchomienie zespołu, forensics, ograniczenie dalszej utraty danych oraz przejrzysty plan powiadomień i działań ochronnych.

Dla osób, których dane mogły zostać ujawnione (inwestorzy)

  • monitoruj alerty dot. kont i rozważ zamrożenie kredytu / alerty fraudowe (w zależności od jurysdykcji),
  • uważaj na wiadomości „o incydencie” (phishing często żeruje na realnych wyciekach),
  • jeżeli w grę wchodzą numery dokumentów – rozważ działania zgodne z lokalnymi procedurami (wymiana dokumentu, zastrzeżenia itd.).
    Wskazówki dot. powiadamiania i kroków ochronnych po wycieku PII FTC opisuje w przewodniku reagowania na naruszenia.

Różnice / porównania z innymi przypadkami

  • To nie jest „klasyczny breach banku”, gdzie atakujący wchodzi do core-systemów. Tu kluczowe jest, że „blast radius” powstał u partnera (kancelarii), a bank komunikuje, że jego środowisko nie zostało naruszone.
  • Ten case pokazuje też, że profesjonalne usługi (legal, advisory) są atrakcyjnym celem: w jednym miejscu kumulują dane wielu klientów, często o wysokiej wartości (HNWI, fundusze, transakcje M&A).

Podsumowanie / kluczowe wnioski

  • Incydent w Fried Frank to przykład, jak ryzyko stron trzecich materializuje się „łańcuchowo” – komunikacja dotyka wielu instytucji naraz (JPMorgan, wcześniej Goldman).
  • Techniczny opis („skopiowanie plików z udziału sieciowego”) sugeruje scenariusz kompromitacji dostępu i ekstrakcji danych, nawet bez widocznych oznak ransomware.
  • Największą lekcją dla rynku jest konieczność przeniesienia nacisku z „czy dostawca ma politykę” na „czy dostawca ma mierzalne kontrole, telemetrykę i minimalny dostęp do danych”.

Źródła / bibliografia

  1. SecurityWeek – „After Goldman, JPMorgan Discloses Law Firm Data Breach”, 13 stycznia 2026. (SecurityWeek)
  2. Bloomberg – informacja o ostrzeżeniu Goldmana i wskazaniu kancelarii Fried Frank, 24 grudnia 2025. (Bloomberg)
  3. Bloomberg Law – opis pozwu dot. naruszenia danych w Fried Frank, 24 grudnia 2025 (aktualizacje tego samego dnia). (Bloomberg Law)
  4. NIST CSRC – status i odniesienie do SP 800-61 (Rev. 2 wycofana w 2025 r.; wskazanie następcy). (csrc.nist.gov)
  5. FTC – „Data Breach Response: A Guide for Business” (zalecenia operacyjne dot. reagowania i notyfikacji). (ftc.gov)

SAP Security Patch Day: styczeń 2026 — 4 krytyczne luki (SQLi/RCE/Code Injection) i co zrobić w pierwszej kolejności

Wprowadzenie do problemu / definicja luki

W styczniowym wydaniu SAP Security Patch Day (opublikowanym 13 stycznia 2026) SAP udostępnił 17 nowych Security Notes, z czego 4 dotyczą podatności o krytycznej ważności (m.in. SQL injection, RCE oraz code injection prowadzące do wykonania komend systemu operacyjnego).

W praktyce oznacza to, że organizacje utrzymujące krajobraz SAP (on-prem, private cloud i hybrydowo) muszą potraktować ten cykl aktualizacji jako „priority patching” — szczególnie tam, gdzie występują ekspozycje RFC, komponenty administracyjne oraz elementy monitoringu/apm.

W skrócie

  • 4 krytyczne CVE:
    • CVE-2026-0501 (CVSS 9.9) — SQL injection w SAP S/4HANA (Financials – General Ledger)
    • CVE-2026-0500 (CVSS 9.6) — RCE w SAP Wily Introscope Enterprise Manager (WorkStation) (wektor przez złośliwy JNLP/URL)
    • CVE-2026-0498 (CVSS 9.1) — code injection w SAP S/4HANA (możliwy OS command injection)
    • CVE-2026-0491 (CVSS 9.1) — code injection w SAP Landscape Transformation (DMIS add-on)
  • SAP zaleca możliwie szybkie wdrożenie poprawek z listy styczniowej.
  • Niezależne analizy (m.in. Onapsis, SecurityBridge) wskazują na realną „operacyjną” istotność: wektory dotykają typowych elementów integracji (RFC), monitoringu oraz komponentów, które bywają pomijane w patchowaniu.

Kontekst / historia / powiązania

„Patch Tuesday” w SAP to stały rytm, ale w ostatnich cyklach rośnie udział podatności, które:

  • uderzają w krytyczne procesy biznesowe (np. finanse w S/4HANA),
  • wykorzystują płaszczyznę integracyjną (RFC i autoryzacje),
  • dotyczą narzędzi operacyjnych (monitoring/management), które często mają szerokie uprawnienia i są dostępne z sieci administracyjnych.

W tym miesiącu szczególnie ważne jest to, że co najmniej część luk dotyczy ścieżek zdalnych (remote-enabled) oraz scenariuszy, w których błąd autoryzacji/validacji wejścia może przełożyć się na eskalację wpływu aż do przejęcia systemu.

Analiza techniczna / szczegóły luki

1) CVE-2026-0501 — SQL injection w SAP S/4HANA (FI-GL)

To klasyczny scenariusz „native SQL” z niewystarczającą walidacją danych wejściowych: uwierzytelniony użytkownik może wykonywać spreparowane zapytania SQL prowadzące do odczytu/modyfikacji/usuwania danych w backendzie bazy, co przekłada się na wysokie ryzyko dla CIA (Confidentiality/Integrity/Availability).

Dlaczego to boli najbardziej? Bo dotyka obszaru General Ledger — manipulacje w warstwie danych finansowych mają bezpośrednie skutki biznesowe (spójność księgi, raportowanie, audyt, rozliczenia).

2) CVE-2026-0500 — RCE w SAP Wily Introscope Enterprise Manager (WorkStation)

W tym przypadku krytyczność wynika z kombinacji:

  • braku wymogu uwierzytelnienia po stronie atakującego (wg opisu),
  • mechanizmu dostarczenia ładunku przez złośliwy plik JNLP dostępny pod URL,
  • oraz skutku w postaci wykonania komend OS po stronie środowiska, które uruchamia/obsługuje komponent.

Praktycznie: jeśli Wily/Introscope jest dostępny z sieci o niższym poziomie zaufania lub użytkownicy administracyjni mogą być podatni na socjotechnikę, rośnie ryzyko łańcucha „phishing → klik → RCE”.

3) CVE-2026-0498 — code injection w SAP S/4HANA (możliwy OS command injection)

Z opisów analityków wynika, że problem dotyczy remote-enabled funkcji, która może pozwalać na modyfikację kodu źródłowego istniejących programów bez odpowiednich kontroli — co może eskalować do OS command injection i pełnej kompromitacji.

Wymagania wejściowe są istotne (np. uprawnienia administracyjne w opisie), ale skutki są tak poważne, że priorytet patchowania pozostaje wysoki.

4) CVE-2026-0491 — code injection w SAP Landscape Transformation (DMIS)

To wariant bardzo podobnego mechanizmu, tyle że w SLT/DMIS add-on — czyli obszarze, który bywa wdrażany „raz i działa”, a potem jest rzadziej aktualizowany niż systemy core.

Praktyczne konsekwencje / ryzyko

Jeśli zostawisz te luki niezałatane, realne scenariusze obejmują:

  • naruszenie integralności danych finansowych (CVE-2026-0501) i długotrwałe skutki audytowe/zgodnościowe,
  • przejęcie hosta/komponentu zarządzającego (CVE-2026-0500), co często daje przyczółek do ruchu bocznego,
  • trwałą kompromitację systemu przez modyfikację kodu (CVE-2026-0498/0491), co utrudnia wykrycie (backdoor w logice ABAP/transportach).

Rekomendacje operacyjne / co zrobić teraz

Priorytet 0: szybka triage i kolejka wdrożeń

  1. Zidentyfikuj, czy masz w krajobrazie komponenty/wersje z listy SAP (S4CORE, WILY_INTRO…, DMIS itd.).
  2. Ustal „blast radius”: które systemy są internet-facing, które mają integracje RFC z wieloma domenami i które trzymają dane wrażliwe.

Priorytet 1: patchowanie „krytyków” (4 CVE)

  • Wdróż poprawki dla CVE-2026-0501 / 0500 / 0498 / 0491 w pierwszym możliwym oknie serwisowym.
  • Jeśli patchowanie wymaga czasu (change freeze/okna), wprowadź kompensacje:

Kompensacje i hardening (gdy nie możesz spatchować od razu)

  • RFC / autoryzacje: zweryfikuj restrykcyjność obiektu S_RFC i ekspozycję remote-enabled funkcji (minimalizacja uprawnień, segmentacja, ograniczenia po hostach). SecurityBridge zwraca uwagę, że błędna konfiguracja autoryzacji może być krytycznym „wzmacniaczem” ryzyka.
  • Wily Introscope: ogranicz dostęp sieciowy (ACL, segmentacja), przejrzyj kto i skąd może inicjować akcje WorkStation/URL; wzmocnij ochronę przed phishingiem dla kont admin
  • Monitoring detekcji: ustaw alerty na nietypowe wywołania RFC, anomalie w transakcjach związanych z transportami/aktywacją obiektów oraz nietypowe zachowania hostów z komponentami APM.

Priorytet 2: nie ignoruj „High”

SAP wskazuje również kilka pozycji High (np. HANA privilege escalation, OS command injection w ABAP/RFCSDK, braki autoryzacji w NetWeaver ABAP/Platform). W praktyce one często stają się drugim krokiem w łańcuchu ataku po zdobyciu dostępu.

Różnice / porównania z innymi przypadkami

  • SQLi vs code injection: SQLi (CVE-2026-0501) najczęściej zaczyna się od „danych”, ale kończy na pełnym wpływie na procesy finansowe; code injection (CVE-2026-0498/0491) uderza w logikę i utrzymanie trwałości (persystencja w kodzie).
  • RCE w narzędziu operacyjnym (CVE-2026-0500) bywa groźniejsze niż „kolejna luka w module biznesowym”, bo tooling (APM/monitoring) ma zwykle szeroki dostęp i jest traktowany jako zaufany.

Podsumowanie / kluczowe wnioski

Styczeń 2026 w SAP to cykl, w którym „krytyki” obejmują zarówno core (S/4HANA), jak i narzędzia operacyjne (Wily Introscope) oraz integracje/transfer danych (SLT/DMIS). Najrozsądniejsza strategia to: patchować 4 krytyczne natychmiast, równolegle uszczelniając RFC, segmentację i monitoring, a następnie szybko domknąć pozycje „High”.

Źródła / bibliografia

  1. SAP — SAP Security Patch Day – January 2026 (SAP Support Portal)
  2. SecurityWeek — SAP’s January 2026 Security Updates Patch Critical Vulnerabilities (SecurityWeek)
  3. Onapsis — SAP Security Notes: January 2026 Patch Day (Onapsis)
  4. SecurityBridge — SAP Security Patch Day – January 2026 (SecurityBridge)
  5. NVD (NIST) — wpisy CVE-2026-0501 oraz CVE-2026-0500 (nvd.nist.gov)

Adobe łata krytyczną lukę w Apache Tika używanym przez ColdFusion (CVE-2025-66516)

Wprowadzenie do problemu / definicja luki

Adobe opublikowało poprawki bezpieczeństwa dla ColdFusion 2025 i ColdFusion 2023, które usuwają krytyczną podatność odziedziczoną po bibliotece Apache Tika – popularnym silniku do analizy plików i ekstrakcji treści/metadata. Luka ma identyfikator CVE-2025-66516 i dotyczy mechanizmu parsowania PDF, w którym możliwy jest atak typu XXE (XML External Entity Injection), wyzwalany przez spreparowane elementy XFA osadzone w dokumencie PDF.

W skrócie

  • Co to jest: XXE w Apache Tika, możliwy do wywołania przez PDF z zawartością XFA.
  • Kogo dotyczy (ColdFusion):
    • ColdFusion 2025 Update 5 i starsze
    • ColdFusion 2023 Update 17 i starsze
  • Naprawione w: ColdFusion 2025 Update 6 oraz 2023 Update 18 (priorytet Adobe: 1 – pilna aktualizacja).
  • Potencjalne skutki udanego ataku (wg ostrzeżeń dot. Tika): wyciek informacji, SSRF, DoS, a w określonych scenariuszach nawet RCE.

Kontekst / historia / powiązania

Problem jest „supply-chainowy”: podatność leży w zależności (Apache Tika), którą wykorzystuje Adobe ColdFusion. Sama Tika opublikowała poprawkę na początku grudnia 2025, a Adobe dopiero w styczniu 2026 dostarczyło aktualizacje ColdFusion, które podbijają/aktualizują podatną zależność.

Warto też zwrócić uwagę, że opis CVE wskazuje na powiązanie z wcześniejszym wpisem CVE-2025-54988: CVE-2025-66516 rozszerza zakres (m.in. akcentując, że poprawka jest w tika-core, a nie tylko w module parsującym PDF, i że w linii 1.x parser był w innym artefakcie Maven). To ma znaczenie dla zespołów, które „łatali punktowo” pojedynczy moduł zamiast całego tika-core.

Analiza techniczna / szczegóły luki

Mechanizm ataku (XXE przez XFA w PDF)

  • Atak XXE polega na tym, że parser XML przetwarza zewnętrzne encje (np. odwołania do zasobów lokalnych lub URL), co może skutkować:
    • odczytem danych z systemu plików (np. plików konfiguracyjnych),
    • wykonaniem żądań sieciowych z wnętrza serwera (SSRF),
    • przeciążeniem zasobów (DoS),
    • a w zależności od kontekstu przetwarzania i dalszych łańcuchów – eskalacją do RCE.

Wersje podatne i poprawki po stronie Tika

Z publicznych opisów wynika, że luka obejmuje m.in.:

  • org.apache.tika:tika-core w zakresie 1.13–3.2.1 (naprawione w 3.2.2),
  • oraz powiązane moduły parsowania PDF/„parsers” w zależności od linii wydań.

Skoring (CVSS) – dlaczego zobaczysz różne liczby

W praktyce możesz spotkać różne oceny „krytyczności” dla tej samej luki (inne wektory/założenia dot. zdalności i warunków ataku). Przykładowo, NVD pokazuje m.in. 9.8 (CRITICAL) w CVSS v3.1, podczas gdy CNA (ASF) ma inny wektor i bazową ocenę 8.4 (HIGH).
Dla zespołów operacyjnych ważniejsze od sporu o liczby jest to, że:

  • podatność dotyczy popularnego silnika parsowania dokumentów,
  • łatwo ją „dotknąć” w systemach przyjmujących nieufne pliki,
  • Adobe nadało poprawce ColdFusion priorytet 1.

Praktyczne konsekwencje / ryzyko

Jeśli Twój ColdFusion (lub inny komponent korzystający z Tika) przetwarza pliki dostarczane z zewnątrz (uploady, integracje, skrzynki wejściowe, automatyzacje), ryzyko rośnie znacząco:

  • Wyciek danych: XXE może próbować „wciągnąć” do odpowiedzi/parser-output treści wrażliwych plików lokalnych.
  • SSRF: serwer może wykonywać połączenia do usług wewnętrznych (np. metadane chmury, panele admin, bazy) — nawet jeśli są niewystawione publicznie.
  • DoS: klasyczne wektory XXE potrafią zabić proces parsowania i zasoby.
  • Potencjalne RCE: SecurityWeek wskazuje, że ostrzeżenia Tika dopuszczają scenariusz RCE jako możliwy skutek udanej eksploatacji (zależnie od środowiska i łańcucha).

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizuj ColdFusion natychmiast (najważniejsze)

  • ColdFusion 2025 → Update 6
  • ColdFusion 2023 → Update 18

Adobe oznaczyło biuletyn jako Priority 1, co praktycznie oznacza „łatamy w pierwszej kolejności”.

2) Zweryfikuj miejsca, gdzie serwer przyjmuje i przetwarza pliki

Skoncentruj się na:

  • uploadach PDF i automatycznym indeksowaniu/analizie treści,
  • integracjach z DMS/ECM, skrzynkami mailowymi, workflow, które „same” parsują dokumenty,
  • endpointach, gdzie plik przechodzi przez ekstrakcję tekstu/metadata.

3) Ogranicz skutki ewentualnej próby XXE/SSRF (defense-in-depth)

  • Egress filtering: blokuj niepotrzebne wyjścia z serwera aplikacyjnego do internetu i sieci wewnętrznych (szczególnie do usług wrażliwych).
  • Segmentacja + minimalne uprawnienia: uruchamiaj ColdFusion na koncie o możliwie niskich uprawnieniach i ogranicz dostęp do systemu plików.
  • Monitoruj logi i anomalie: nietypowe próby przetwarzania PDF, błędy parsera, skoki użycia CPU/RAM, nietypowe połączenia wychodzące.

4) Jeśli nie możesz zaktualizować „dziś”

To sytuacja awaryjna — krótkoterminowo:

  • ogranicz/wyłącz funkcje przetwarzania nieufnych PDF,
  • odetnij możliwość uploadu PDF z internetu,
  • wprowadź blokady na warstwie WAF/reverse proxy dla podejrzanych wzorców uploadu i zwiększ obserwowalność ruchu.

Różnice / porównania z innymi przypadkami

CVE-2025-66516 vs CVE-2025-54988: to w praktyce „ta sama klasa problemu”, ale CVE-2025-66516 rozszerza i porządkuje zakres (kluczowe: poprawka w tika-core, różnice między linią 1.x i 2.x/3.x w artefaktach). To istotne, bo błędne „łatki zależności” (np. aktualizacja tylko parsera PDF bez core) mogą pozostawić system nadal podatny.

Podsumowanie / kluczowe wnioski

  • Adobe załatało w ColdFusion krytyczny problem pochodzący z Apache Tika: CVE-2025-66516 (XXE przez XFA w PDF).
  • Podatne są: ColdFusion 2025 Update 5 i starsze oraz ColdFusion 2023 Update 17 i starsze; naprawa: 2025 Update 6 i 2023 Update 18.
  • Jeśli Twój system przetwarza nieufne dokumenty, ryzyka obejmują wyciek danych, SSRF, DoS, a potencjalnie także RCE w sprzyjających warunkach.
  • Najlepsza strategia: aktualizacja + ograniczenie przetwarzania nieufnych plików + kontrola ruchu wychodzącego.

Źródła / bibliografia

  1. Adobe Security Bulletin: Security updates available for Adobe ColdFusion | APSB26-12 (Adobe Help Center)
  2. SecurityWeek: Adobe Patches Critical Apache Tika Bug in ColdFusion (SecurityWeek)
  3. NVD (NIST): CVE-2025-66516 (nvd.nist.gov)
  4. Apache Tika: Security (lista CVE, w tym CVE-2025-54988/XXE w PDFParser) (Apache Tika)
  5. GitHub Advisory Database: GHSA-f58c-gq56-vjjf / CVE-2025-66516 (zakres wersji, patched versions) (GitHub)

CISA nakazuje pilne łatanie luki RCE w Gogs (CVE-2025-8110) wykorzystywanej jako 0-day

Wprowadzenie do problemu / definicja luki

Gogs (lekka, self-hostowana usługa Git napisana w Go) znalazła się na celowniku po potwierdzeniu aktywnego wykorzystywania podatności CVE-2025-8110 prowadzącej do zdalnego wykonania kodu (RCE) na serwerach wystawionych do Internetu. CISA nakazała amerykańskim agencjom federalnym wdrożenie poprawek/mitigacji w trybie pilnym — w praktyce to sygnał, że ryzyko jest „tu i teraz”, a nie teoretyczne.

W skrócie

  • CVE-2025-8110 (CVSS v4: 8.7 / High) dotyczy obsługi dowiązań symbolicznych (symlinków) w API zapisu plików PutContents i umożliwia zapis poza repozytorium.
  • Atak wymaga zwykle niskich uprawnień (np. konta użytkownika), ale w praktyce wiele instancji ma włączone Open Registration, co mocno obniża barierę wejścia.
  • Wiz raportował ponad 700 oznak skompromitowanych instancji i ponad 1400 publicznie dostępnych serwerów Gogs podczas analizy kampanii.
  • CISA wyznaczyła termin dla FCEB na 2 lutego 2026 (w ciągu 3 tygodni od komunikatu).

Kontekst / historia / powiązania

CVE-2025-8110 jest opisywana jako obejście wcześniej załatanego błędu RCE CVE-2024-55947. Poprzednie zabezpieczenia miały blokować klasyczny directory traversal w ścieżkach, ale nie weryfikowały celu symlinka, co pozwoliło wrócić do scenariusza „zapis poza repozytorium → przejęcie”.

Z perspektywy obrony istotne są też informacje o falach ataków: Wiz opisał obserwacje działań już latem, a następnie kolejną falę (wg osi czasu ujawnienia) 1 listopada.

Analiza techniczna / szczegóły luki

Rdzeń problemu: PutContents API pozwala aktualizować/zapisywać pliki w repozytorium przez endpoint w stylu:

  • PUT /repos/:owner/:repo/contents/:path

Aplikacja walidowała ../ (traversal po ścieżce), ale nie walidowała docelowej ścieżki po rozwinięciu symlinków. Atakujący może więc:

  1. Utworzyć repozytorium zawierające symlink (np. do pliku konfiguracyjnego Git poza repo).
  2. Z użyciem PutContents zapisać dane „przez symlink”, co w efekcie nadpisze plik poza katalogiem repozytorium.

W praktyce opisywany wektor eskalacji do RCE to nadpisanie .git/config i wstrzyknięcie ustawienia sshCommand, które następnie może zostać użyte do uruchomienia dowolnych poleceń przy kolejnej operacji Git.

Status poprawek bywa mylący:

  • istnieją patche/commity/PR dodające „symlink-aware path validation” (walidację ścieżek po rozwinięciu dowiązań),
  • natomiast w bazie advisory GitHub nadal może widnieć informacja o braku „patched versions” jako wydań wersji (tagów) — co z perspektywy zespołów operacyjnych oznacza często: trzeba wdrożyć poprawkę z kodu źródłowego albo zastosować twarde mitigacje do czasu oficjalnego release’u.

Praktyczne konsekwencje / ryzyko

Najbardziej narażone są instancje:

  • wystawione do Internetu,
  • z włączoną otwartą rejestracją (Open Registration),
  • gdzie PutContents jest dostępne dla szerokiej grupy użytkowników.

Skutki kompromitacji mogą obejmować:

  • przejęcie serwera aplikacyjnego (RCE w kontekście procesu Gogs),
  • kradzież repozytoriów/sekretów (tokeny, klucze wdrożeniowe, konfiguracje CI/CD),
  • pivot do sieci wewnętrznej (Gogs bywa „blisko” pipeline’ów i systemów budowania).

W jednej z analiz kampanii wskazano użycie malware budowanego na Supershell (framework C2), komunikującego się m.in. z adresem 119.45.176[.]196 — to ważny IOC dla threat huntingu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej podejście „assume breach” dla organizacji, które mają Gogs online.

1) Redukcja powierzchni ataku (natychmiast)

  • Wyłącz Open Registration (jeśli nie jest absolutnie konieczne).
  • Ogranicz dostęp do Gogs: VPN / allowlista IP / reverse proxy z ACL, minimum ekspozycji publicznej.
  • Jeśli możesz: czasowo zablokuj lub ogranicz operacje zapisu przez API (w tym PutContents) na brzegu (proxy/WAF) — z uwzględnieniem, że może to uderzyć w legalne integracje.

2) Remediacja (patch lub backport)

  • Jeśli masz możliwość utrzymania własnej paczki: rozważ wdrożenie poprawek z upstream (walidacja po EvalSymlinks / blokada ścieżek „uciekających” poza repo) jako hotfix do czasu oficjalnego wydania.
  • Monitoruj stan advisory i wydań; CVE obejmuje wersje ≤ 0.13.3 wg GitHub Advisory.

3) Detekcja kompromitacji (logi + artefakty)

  • W logach aplikacji/reverse proxy szukaj nietypowego użycia PutContents API (skoki wolumenu, nietypowe ścieżki, serie zapytań PUT).
  • Przeskanuj repozytoria pod kątem:
    • repo z losowymi 8-znakowymi nazwami tworzonymi w krótkim oknie czasu,
    • obecności symlinków prowadzących poza repo.
  • Sprawdź pliki .git/config pod kątem podejrzanych wpisów (zwłaszcza sshCommand) i przejrzyj, czy na serwerze nie pojawiły się dodatkowe binaria/usługi utrzymujące dostęp.

4) Reakcja po incydencie

Jeżeli instancja była publiczna i nie masz pewności, czy doszło do nadużyć:

  • potraktuj host jako potencjalnie przejęty,
  • rotuj sekrety (tokeny, klucze deploy, integracje),
  • przeprowadź izolację i analizę (EDR / forensics), zanim przywrócisz usługę do Internetu.

5) Kontekst regulacyjny (dlaczego to pilne)

CISA wymaga od FCEB wdrożenia działań do 2 lutego 2026, co zwykle koreluje z realnym ryzykiem i dostępnością działających łańcuchów ataku w „dzikiej” eksploatacji.

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

Ten przypadek jest dobrym przykładem „patch bypass”:

  • wcześniejsza łatka (CVE-2024-55947) zaadresowała traversal na poziomie stringów ścieżek,
  • ale brak walidacji po rozwinięciu symlinków pozostawił furtkę, którą da się zautomatyzować w atakach masowych.

To częsty wzorzec także w innych produktach: „zapis pliku + niedoszacowanie symlinków / canonicalization” kończy się arbitrary file write, a to bardzo często jest już tylko krok od RCE.

Podsumowanie / kluczowe wnioski

  • CVE-2025-8110 to realnie wykorzystywana podatność w Gogs, umożliwiająca arbitrary file write → RCE przez symlinki i PutContents API.
  • Priorytetem jest odcięcie ekspozycji (VPN/allowlista), wyłączenie otwartej rejestracji i wdrożenie poprawek/mitigacji najszybciej jak to możliwe.
  • Dla instancji internet-facing warto równolegle uruchomić threat hunting (PutContents, losowe repo, .git/config, sshCommand, IOC od C2).

Źródła / bibliografia

  1. BleepingComputer: CISA orders feds to patch Gogs RCE flaw exploited in zero-day attacks (12 stycznia 2026). (BleepingComputer)
  2. Wiz Research: Gogs 0-Day Exploited in the Wild (CVE-2025-8110) (10 grudnia 2025). (wiz.io)
  3. NVD / NIST: wpis CVE-2025-8110 (CVSS v4 8.7 / CVSS v3.1 8.8). (NVD)
  4. GitHub Advisory Database: GHSA-mq8m-42gh-wq7r / CVE-2025-8110 (status wersji dotkniętych). (GitHub)
  5. Gogs/GitHub: PR z opisem i mechaniką poprawki (walidacja symlinków w punktach zapisu). (GitHub)