Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 372 z 487

Autor: Wojciech Ciemski

Nowe „sandbox escape” w n8n: CVE-2026-1470 i CVE-2026-0863 otwierają drogę do RCE na self-hosted instancjach

Wprowadzenie do problemu / definicja luki

n8n to popularna platforma do automatyzacji workflow (często także dla integracji z narzędziami AI/LLM), którą organizacje uruchamiają zarówno w chmurze, jak i w modelu self-hosted. Problem zaczyna się wtedy, gdy „niezaufana” logika użytkownika (wyrażenia JavaScript i fragmenty kodu Python w węzłach workflow) jest wykonywana w środowisku, które ma być odseparowane od hosta – ale w praktyce da się z tej piaskownicy uciec.

W dniach 27–28 stycznia 2026 opisano dwa takie przypadki: CVE-2026-1470 (krytyczna, CVSS 9.9) oraz CVE-2026-0863 (wysoka, CVSS 8.5). Obie luki pozwalają uwierzytelnionemu użytkownikowi z uprawnieniami do tworzenia/edycji workflow doprowadzić do zdalnego wykonania kodu (RCE) i przejęcia instancji – a w pewnych konfiguracjach nawet hosta.

W skrócie

  • CVE-2026-1470 (CVSS 9.9, Critical): ucieczka z sandboxa w silniku wyrażeń (Expression Engine) poprzez obejście walidacji AST w JavaScript; finalnie prowadzi do RCE w głównym procesie n8n.
  • CVE-2026-0863 (CVSS 8.5, High): ucieczka z sandboxa dla Python Code node (zwłaszcza w trybie Internal) z wykorzystaniem zachowania wyjątków w Python 3.10+; w „Internal” może skutkować przejęciem całej instancji na hoście.
  • Dotyczy głównie self-hosted (n8n cloud ma mieć poprawki wdrożone), a kluczowe jest szybkie przejście na wersje naprawione.

Kontekst / historia / powiązania

W praktyce n8n działa jak „centralny węzeł automatyzacji” – ma dostęp do webhooków, sekretów, tokenów API, systemów IAM, narzędzi DevOps i danych biznesowych. To sprawia, że nawet „tylko” post-auth RCE jest bardzo groźne: użytkownik o pozornie ograniczonych prawach (np. edycja workflow) może stać się punktem wejścia do przejęcia infrastruktury.

Badacze JFrog podkreślają, że mimo wzmacniania mechanizmów ochronnych w n8n, złożone cechy języków dynamicznych (JS/Python) i zmiany zachowań runtime potrafią rozbić założenia sandboxa.

Analiza techniczna / szczegóły luki

CVE-2026-1470: JavaScript „Expression Engine” i pominięty edge-case with

Mechanizm wyrażeń n8n opiera się na wykonywaniu treści {{ ... }} poprzez konstruktor JavaScript Function, co z natury jest ryzykowne. Dlatego n8n stosuje AST-based sandbox (m.in. walidacje i neutralizację niebezpiecznych konstrukcji). JFrog opisuje jednak, że jeden problematyczny element został przeoczony: instrukcja with (przestarzała, ale wciąż wspierana), która zmienia sposób rozwiązywania identyfikatorów w zakresie. Skutkiem jest możliwość „oszukania” walidacji AST tak, by obejść blokady i doprowadzić do uruchomienia dowolnego kodu w kontekście głównego procesu n8n.

Dlaczego CVSS aż 9.9 mimo wymogu logowania? Bo wykonanie następuje na głównym node n8n, co daje realnie pełne przejęcie instancji (a często i hosta) przy niskim progu uprawnień (wystarczy możliwość edycji workflow).

CVE-2026-0863: Python Code node, AST sandbox i „ucieczka przez wyjątki” (Python 3.10+)

Druga luka dotyczy wykonywania Pythona w Code node i obejścia restrykcji sandboxa (opartego o analizę AST, denylisty builtins/importów itp.). Kluczowy element to fakt, że od Python 3.10 obiekty wyjątków typu AttributeError zyskały dodatkowe pola (m.in. obj), co może zostać wykorzystane do odzyskania referencji do obiektów, które sandbox próbował ukryć. W efekcie, przy sprytnym łańcuchu działań (bez potrzeby klasycznych, wprost zakazanych wywołań), możliwe staje się obejście ograniczeń i dojście do wykonania poleceń systemowych.

Bardzo ważne jest tu rozróżnienie trybów uruchomienia:

  • Internal mode: task runner jest procesem potomnym n8n (ta sama tożsamość/UID/GID), co zwiększa skutki kompromitacji.
  • External mode: kod wykonuje się w sidecarze (oddzielny kontener/runner), co zwykle ogranicza wpływ na hosta (choć nadal jest to poważny incydent).

Praktyczne konsekwencje / ryzyko

Jeśli atakujący ma konto (lub przejmie konto) z uprawnieniami do tworzenia/edycji workflow, może:

  • uzyskać RCE i przejąć instancję n8n (a przez to dostęp do sekretów, tokenów, połączeń z systemami firmy),
  • modyfikować workflow w celu trwałej persystencji (np. „ciche” eksfiltracje lub dalsze skrypty),
  • wykonać ruch boczny (lateral movement) do narzędzi, które n8n integruje (CI/CD, chmura, SaaS, IAM).

W konfiguracjach Internal mode ryzyko jest szczególnie wysokie, bo udana ucieczka z sandboxa oznacza wykonywanie komend w kontekście głównego środowiska n8n. Sama dokumentacja n8n ostrzega, że internal w produkcji to ryzyko bezpieczeństwa i zaleca external.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj n8n do wersji z poprawkami:
    • dla CVE-2026-1470: 1.123.17 / 2.4.5 / 2.5.1 (lub nowsze)
    • dla CVE-2026-0863: 1.123.14 / 2.3.5 / 2.4.2 (lub nowsze)
  2. Wymuś „External mode” dla task runners (szczególnie jeśli korzystasz z Code node) – to domyślna rekomendacja do produkcji, bo zapewnia izolację przez sidecar/runner.
  3. Ogranicz uprawnienia do tworzenia/edycji workflow (RBAC/least privilege): traktuj je jak uprawnienia „prawie administracyjne”, bo w razie luki sandboxowej to realny wektor przejęcia.
  4. Segmentacja i ograniczenia sieciowe: jeśli n8n musi mieć dostęp do systemów wewnętrznych, ogranicz to listami dozwolonych adresów/usług; rozważ osobne środowiska dla automatyzacji „wysokiego zaufania”.
  5. Rotacja sekretów po aktualizacji, jeśli istnieje podejrzenie nadużycia (tokeny API, hasła integracji, klucze chmurowe). W przypadku RCE zakładaj kompromitację poufności.
  6. Monitoring: wykrywaj nietypowe modyfikacje workflow (nowe węzły Code/Expression, zmiany w webhookach, nowe integracje), skoki w uruchomieniach i nieoczekiwane połączenia wychodzące.

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

  • JavaScript vs Python: w obu przypadkach problemem jest zaufanie do AST-based sandbox i to, że drobne szczegóły języka/runtime mogą stworzyć „furtkę” poza założony model bezpieczeństwa.
  • Wpływ konfiguracji: CVE-2026-0863 wyraźnie eskaluje w Internal mode, podczas gdy external (sidecar) może ograniczać zasięg skutków.
  • Wspólny mianownik: atak wymaga co prawda uwierzytelnienia, ale w realnych środowiskach „edytor workflow” to częsta rola operacyjna – a n8n bywa wystawiane w sieci firmowej (czasem też publicznie), co podnosi ryzyko.

Podsumowanie / kluczowe wnioski

CVE-2026-1470 i CVE-2026-0863 to kolejny sygnał, że sandboxowanie JavaScript i Pythona w produktach automatyzacji jest wyjątkowo trudne do „domknięcia” na stałe. W praktyce bezpieczeństwo n8n zależy nie tylko od patchy, ale też od modelu uruchomienia (external vs internal) oraz od tego, komu dajemy możliwość edycji workflow.

Jeśli masz self-hosted n8n: patchuj pilnie, przełącz na external mode dla task runners i potraktuj uprawnienia do workflow jako zasób krytyczny.

Źródła / bibliografia

  • BleepingComputer – opis CVE-2026-1470 i CVE-2026-0863, wersje naprawione, kontekst zagrożenia (28 stycznia 2026). (BleepingComputer)
  • JFrog Security Research – szczegóły techniczne obejść sandboxa (27 stycznia 2026). (research.jfrog.com)
  • National Vulnerability Database (NVD) – karty CVE-2026-1470 i CVE-2026-0863 (metryki, opis, wektory). (NVD)
  • Dokumentacja n8n – task runners, tryby internal/external i ostrzeżenie dot. produkcji. (docs.n8n.io)
  • The Hacker News – podsumowanie, zalecane wersje aktualizacji i akcent na ryzyko w trybie internal. (The Hacker News)

FBI przejmuje forum RAMP – ważny cios w ekosystem ransomware i handel „initial access”

Wprowadzenie do problemu / definicja luki

W świecie cyberprzestępczym fora i „marketplace’y” pełnią rolę infrastruktury krytycznej: to tam łączy się popyt (ransomware-as-a-service, brokerzy dostępu, sprzedawcy malware) z podażą (afilianci, „operatorzy”, pośrednicy od prania pieniędzy, sprzedawcy exploitów). Przejęcie takiego węzła rzadko kończy ransomware „w ogóle”, ale potrafi na pewien czas realnie spowolnić rekrutację afiliantów, handel dostępami do sieci (initial access) i dystrybucję narzędzi.

Właśnie w tym kontekście warto patrzeć na przejęcie RAMP (Russian Anonymous Marketplace) – rosyjskojęzycznego forum, które otwarcie dopuszczało promocję operacji ransomware.

W skrócie

  • 28 stycznia 2026 r. FBI przejęło zarówno wersję Tor, jak i clearnetową domenę forum ramp4u[.]io, zastępując je banerem „This site has been seized”.
  • Na banerze wskazano koordynację z U.S. Attorney’s Office for the Southern District of Florida oraz DOJ CCIPS (Computer Crime and Intellectual Property Section).
  • Widoczne są też techniczne ślady przejęcia: m.in. zmiana serwerów nazw na ns1.fbi.seized.gov i ns2.fbi.seized.gov.
  • Jeden z rzekomych operatorów („Stallman”) miał publicznie potwierdzić przejęcie.

Kontekst / historia / powiązania

RAMP wystartował w lipcu 2021 r. jako odpowiedź na sytuację, w której duże rosyjskojęzyczne fora (m.in. Exploit i XSS) zaczęły ograniczać/banować promocję ransomware pod rosnącą presją organów ścigania po głośnych incydentach (np. Colonial Pipeline). RAMP pozycjonował się jako jedno z niewielu miejsc, gdzie „ransomware jest dozwolone” – co szybko przyciągnęło gangi i afiliantów.

Wątek personalny jest równie istotny: według ustaleń opisywanych w materiałach, z RAMP wiązano postać działającą pod pseudonimem Orange (aliasy m.in. Wazawaka/BorisElcin), łączoną z ekosystemem Babuk; w tle pojawia się również Mikhail Matveev, oskarżany przez USA o udział w operacjach ransomware (m.in. LockBit, Babuk, Hive) i objęty sankcjami.

Analiza techniczna / szczegóły „takedownu”

Z perspektywy operacyjnej przejęcie RAMP jest klasycznym przykładem „domain seizure + takeover” z kilkoma elementami, które warto odnotować:

  1. Jednoczesne przejęcie Tor i clearnetu
    Fakt, że komunikat zajęcia pojawił się i na domenie publicznej, i na usłudze .onion, sugeruje działanie ukierunkowane na pełne odcięcie kanałów dostępu oraz redukcję możliwości „szybkiego powrotu” przez prostą zmianę domeny frontowej.
  2. Zmiana DNS/NS na infrastrukturę „seized”
    Przestawienie serwerów nazw na ns1.fbi.seized.gov / ns2.fbi.seized.gov jest technicznym potwierdzeniem, że organ ścigania uzyskał kontrolę nad kluczowym zasobem w warstwie DNS, co zwykle towarzyszy realizacji nakazów zajęcia.
  3. Wartość dowodowa danych forum
    W scenariuszu przejęcia infrastruktury forum, organy ścigania mogą potencjalnie uzyskać dostęp do danych takich jak: adresy e-mail, logi IP, wiadomości prywatne, metadane transakcji, wątki dot. sprzedaży dostępów itp. Wprost wskazywano, że brak odpowiedniego OPSEC może teraz przełożyć się na identyfikację i aresztowania.
  4. Efekt psychologiczny i dezintegracyjny
    Baner „trollujący” operatorów (odwołanie do hasła RAMP) pełni rolę komunikatu: „mamy kontrolę”, co zwykle zwiększa panikę wśród użytkowników i przyspiesza rozpad zaufania oraz migrację – często chaotyczną.

Praktyczne konsekwencje / ryzyko

Dla organizacji (obrońców)

  • Krótkoterminowe przetasowania w podziemiu: po takedownie często rośnie aktywność na alternatywnych forach/marketach, a brokerzy dostępu próbują szybko „odbudować kanały sprzedaży”. To okres zwiększonego szumu, ale też okazja do lepszego mapowania TTP i relacji.
  • Ryzyko wtórne: część aktorów może próbować „odkuć się” bardziej agresywnymi kampaniami phishingowymi, infostealerami i masową sprzedażą dostępów, by zrekompensować utracone kontakty/escrow.

Dla cyberprzestępców

  • Wzrost ryzyka deanonymizacji przy słabym OPSEC (powtarzalne aliasy, te same skrzynki e-mail, logowania bez tor/VPN, błędy w separacji person).
  • Utrata reputacji i escrow: na forach „zaufanie” jest walutą. Zniknięcie RAMP wymusza weryfikacje od nowa, co często prowadzi do konfliktów, scamów i rozłamów.

Rekomendacje operacyjne / co zrobić teraz

Jeśli odpowiadasz za bezpieczeństwo (SOC/CTI/IR), potraktuj ten moment jako szansę na podniesienie gotowości:

  1. Podnieś czujność na „initial access”
    Zwiększ korelację alertów dla: nietypowych logowań (VPN/RDP/VDI), anomalii w IAM, nowych tokenów OAuth, podejrzanych rejestracji urządzeń, i prób ruchu lateralnego. RAMP był wykorzystywany do handlu dostępami – migracja może podbić wolumen.
  2. Wzmocnij kontrolę tożsamości
    • MFA odporne na phishing (FIDO2/WebAuthn) tam, gdzie to realne
    • przegląd kont uprzywilejowanych, rotacja sekretów, ograniczenie stałych uprawnień
    • polityki „impossible travel” i detekcja proxy/VPN exit nodes
  3. Przygotuj scenariusze ransomware-ready
    • test odtwarzania kopii (nie tylko „backup exists”, ale „restore działa”)
    • izolacja domen/segmentacja, kontrola ruchu SMB/RDP/WinRM
    • gotowe playbooki: containment, komunikacja, decyzje dot. wyłączania usług
  4. Uważaj na „nowe fora” i podszycia
    Po głośnych przejęciach często rośnie liczba scam-forów i kampanii podszywających się pod „następcę”, co bywa wykorzystywane także do infekowania przestępców (infostealery), ale przy okazji może zwiększać liczbę wycieków narzędzi do sieci publicznej.

Różnice / porównania z innymi przypadkami

RAMP wyróżniał się tym, że był jednym z ostatnich dużych hubów pozwalających wprost na promocję ransomware. Dlatego jego utrata jest bardziej „systemowa” niż przejęcie pojedynczej grupy czy strony wyciekowej.

Z doświadczeń poprzednich takedownów wynika, że:

  • ekosystem nie znika, tylko migruje (często na kilka konkurencyjnych platform),
  • okres przejściowy generuje tarcia, scamy i błędy OPSEC,
  • dla obrońców to moment, w którym warto intensywniej zbierać sygnały o nowych kanałach rekrutacji i sprzedaży dostępów.

Podsumowanie / kluczowe wnioski

Przejęcie RAMP przez FBI (28 stycznia 2026 r.) to realne zakłócenie infrastruktury wspierającej ransomware-as-a-service, rekrutację afiliantów i rynek „initial access”.
Najważniejsze efekty będą prawdopodobnie widoczne w dwóch obszarach:

  • operacyjnym (przerwanie kanałów handlu i komunikacji, migracja),
  • kontrwywiadowczym (potencjalny dostęp organów ścigania do danych użytkowników i metadanych aktywności).

Dla organizacji to dobry moment, by założyć, że część aktorów „przegrupuje się” i spróbuje odzyskać tempo – a więc wzmocnić detekcję, IAM, backup/restore oraz gotowość IR.

Źródła / bibliografia

  • BleepingComputer – informacje o przejęciu, banerze, DNS i historii RAMP (BleepingComputer)
  • The Register – uzupełnienie kontekstu, komentarze dot. migracji i znaczenia dla ekosystemu (The Register)
  • U.S. Department of Justice (DOJ) – tło dot. Matveeva (LockBit/Babuk/Hive), CCIPS, nagroda do $10M (Department of Justice)
  • U.S. Treasury (OFAC) – sankcje na Matveeva i szerszy kontekst rosyjskiego ekosystemu ransomware (U.S. Department of the Treasury)

eScan: przejęty serwer aktualizacji posłużył do dystrybucji złośliwego „update” (supply chain) – co wiemy i jak reagować

Wprowadzenie do problemu / definicja luki

Incydenty typu supply chain (kompromitacja łańcucha dostaw) należą do najgroźniejszych, bo nadużywają mechanizmu, któremu organizacje ufają najbardziej: legalnych aktualizacji. W przypadku eScan (MicroWorld Technologies) potwierdzono, że nieautoryzowany plik trafił do ścieżki dystrybucji aktualizacji w obrębie jednego z regionalnych klastrów serwerów, a następnie został pobrany przez część klientów w ograniczonym oknie czasowym 20 stycznia 2026 r.

W skrócie

  • eScan potwierdził nieautoryzowany dostęp do konfiguracji regionalnego serwera aktualizacji i dystrybucję błędnego/złośliwego pliku w kanale update w dniu 20.01.2026 (wąskie okno czasowe, wybrany klaster).
  • Morphisec opisał kampanię jako wieloetapową infekcję opartą o podmieniony komponent aktualizacji (m.in. Reload.exe) oraz dalsze payloady (m.in. CONSCTLX.exe), z naciskiem na „anti-remediation” (blokowanie przyszłych aktualizacji).
  • Kluczowy problem operacyjny: na systemach dotkniętych incydentem automatyczna naprawa/aktualizacja może nie działać, bo malware celowo psuje mechanikę aktualizacji.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy eScan pojawia się w kontekście nadużyć aktualizacji. W 2024 r. opisywano operację przypisywaną aktorom powiązanym z Koreą Płn., gdzie mechanizm aktualizacji eScan miał zostać wykorzystany do dostarczania backdoorów i minerów (kampania określana m.in. jako GuptiMiner) – tam scenariusz obejmował manipulację ruchem/aktualizacją (MitM) i podmianę paczki.
Różnica w 2026 r. jest zasadnicza: tym razem mówimy o dystrybucji przez legalną infrastrukturę aktualizacji (zaufany kanał vendorowy), co zwykle zwiększa „skuteczność” kampanii i utrudnia wczesne wykrycie.

Analiza techniczna / szczegóły luki

Z perspektywy TTP (tactics/techniques/procedures) w opisie Morphisec przewijają się trzy szczególnie niebezpieczne elementy:

1) Trojanizacja komponentu aktualizacji (Stage 1)
Atak miał zacząć się od podmiany 32-bitowego komponentu związanego z aktualizacją – wskazywany jest Reload.exe – który następnie realizował persistence, wykonywanie poleceń i przygotowanie gruntu pod kolejne etapy.

2) „Anti-remediation”: blokowanie przyszłych aktualizacji i naprawy
Złośliwy kod miał modyfikować m.in. plik HOSTS oraz elementy konfiguracji/rejestru eScan tak, aby utrudnić komunikację z serwerami aktualizacji i uniemożliwić pobieranie kolejnych definicji/patche’y. To klasyczny wzorzec: utrzymać foothold i „odciąć” ofiarę od leczenia.

3) Persistence przez Scheduled Tasks + artefakty w rejestrze (Stage 2/3)
Morphisec opisuje m.in. tworzenie zadań harmonogramu podszywających się pod defragmentację (np. nazwy w stylu Windows\Defrag\…Defrag, przykładowo „CorelDefrag”) oraz podejrzane klucze w HKLM\Software\{GUID} z danymi w formie tablicy bajtów (PowerShell payload).

C2 / infrastruktura
Wskazano też przykładowe adresy C2 i zasoby pobierania kolejnych payloadów (w publikacjach zwykle podawane w formie zanonimizowanej typu hxxps://… i [.]). W praktyce SOC powinien dodać je do blokad na brzegu sieci i w DNS/Proxy, a następnie skorelować z logami. (

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka dla organizacji korzystających z eScan:

  • Utrata zaufania do kanału aktualizacji: nawet poprawnie zarządzany endpoint może zostać zainfekowany „legalnym” update’em.
  • Zablokowanie aktualizacji definicji AV/EDR: jeśli mechanizm aktualizacji zostanie uszkodzony, stacja robocza może pozostać w stanie „ślepoty” na nowe próbki i IOC.
  • Trwała obecność (persistence) i możliwość dalszej eskalacji: opisywane backdoory/downloader’y (np. CONSCTLX.exe) sugerują gotowość do dogrywania kolejnych modułów (kradzież danych, lateral movement, ransomware).
  • Ryzyko wtórnych kompromitacji: Morphisec rekomenduje także reset poświadczeń, jeśli zainfekowane hosty mogły uzyskać dostęp do kont/zasobów (typowy następny krok po supply chain).

Rekomendacje operacyjne / co zrobić teraz

Jeśli macie eScan w środowisku (enterprise lub consumer), sensowny playbook „tu i teraz”:

  1. Ustal ekspozycję na okno 20.01.2026
    • Przejrzyj logi aktualizacji eScan oraz ruch sieciowy z tego dnia, zwłaszcza jeśli endpointy korzystały z regionalnych serwerów/CDN.
  2. Traktuj dotknięte hosty jak potencjalnie skompromitowane
    • Izoluj z sieci systemy, na których wystąpiły symptomy: błędy aktualizacji, komunikaty o niedostępności update, zmiany w HOSTS, brak nowych definicji.
  3. Polowanie na IOC (endpoint + AD + sieć)
    • Szukaj: Reload.exe (nietypowe hashe/ścieżki), CONSCTLX.exe, zadań w Windows\Defrag\, podejrzanych kluczy HKLM\Software\{GUID} z danymi binarnymi, katalogów-znaczników (np. opisywany efirst w ProgramData).
  4. Zablokuj infrastrukturę C2
    • Dodaj domeny/IP z raportu do blokad (DNS sinkhole, proxy, firewall) i sprawdź historię połączeń.
  5. Naprawa eScan może wymagać działania manualnego
    • Morphisec podkreśla, że na zainfekowanych systemach automatyczne „doleczenie” może nie zadziałać, bo mechanizm aktualizacji został celowo uszkodzony — wymagany jest kontakt z vendorem i ręczne zastosowanie patcha/narzędzia naprawczego.
  6. Forensics i higiena poświadczeń
    • Zweryfikuj, czy doszło do uruchomienia Stage 3/backdoora; w razie potwierdzenia – pełne IR: timeline, triage pamięci, przegląd kont uprzywilejowanych, rotacja haseł/tokenów.

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

2024 (GuptiMiner) vs 2026 (kompromitacja serwera/klastra aktualizacji):

  • 2024: opisywano scenariusz, w którym atakujący podmieniają paczkę aktualizacji w trakcie dostarczania (MitM / słabe zabezpieczenia kanału).
  • 2026: według potwierdzenia eScan i analizy Morphisec, złośliwy plik był dystrybuowany przez legalną infrastrukturę aktualizacji (co zwykle bardziej przypomina klasyczne supply chain w stylu „zaufany update staje się wektorem ataku”).

Wniosek praktyczny: nawet jeśli organizacja „nie klika w linki” i ma twarde polityki, update pipeline dostawcy pozostaje krytycznym punktem ryzyka, który warto obejmować monitoringiem (np. allowlisting hash/certyfikatów + anomalia w zachowaniu procesu aktualizacji).

Podsumowanie / kluczowe wnioski

  • Incydent eScan to klasyczny atak na łańcuch dostaw, gdzie legalny kanał aktualizacji posłużył do dystrybucji malware w dniu 20 stycznia 2026 r.
  • Kluczową cechą kampanii jest blokowanie mechanizmu naprawy/aktualizacji (HOSTS + konfiguracja/rejestr eScan), co podnosi koszt i czas reakcji.
  • Najrozsądniejsze podejście: szybko ustalić ekspozycję, izolować podejrzane hosty, wykonać threat hunting po IOC, zablokować C2 i wdrożyć manualną ścieżkę remediation rekomendowaną przez vendor/partnerów badawczych.

Źródła / bibliografia

  1. BleepingComputer – potwierdzenie incydentu przez MicroWorld/eScan, symptomy, kontekst i odniesienia do analizy Morphisec. (BleepingComputer)
  2. Morphisec Threat Labs – „Threat Bulletin: Critical eScan Supply Chain Compromise” (łańcuch infekcji, IOC, persistence, remediation). (Morphisec)
  3. SC Media (SCWorld) – streszczenie incydentu i rekomendacje działań operacyjnych (threat hunting, blokady C2, ostrożność wobec certyfikatu). (SC Media)
  4. SecurityWeek – tło historyczne: kampania 2024 wykorzystująca mechanizm aktualizacji eScan (GuptiMiner, MitM). (SecurityWeek)

SolarWinds Web Help Desk: krytyczne luki (RCE i bypass uwierzytelniania) – co wiemy i jak zareagować

Wprowadzenie do problemu / definicja luki

SolarWinds załatał zestaw poważnych podatności w produkcie Web Help Desk (WHD) – systemie do obsługi zgłoszeń i zasobów IT. W praktyce jest to oprogramowanie, które często działa jako aplikacja serwerowa dostępna dla wielu użytkowników (czasem niestety także z Internetu), a więc stanowi atrakcyjny cel ataków.

W opublikowanych informacjach kluczowe są cztery podatności ocenione jako krytyczne (CVSS 9.8), obejmujące zdalne wykonanie kodu (RCE) bez uwierzytelnienia oraz obejście uwierzytelniania (auth bypass).

W skrócie

  • 4× krytyczne (9.8):
    • CVE-2025-40551 i CVE-2025-40553 – deserializacja niezaufanych danych → RCE bez logowania
    • CVE-2025-40552 i CVE-2025-40554 – bypass uwierzytelniania / wykonywanie akcji, które powinny wymagać logowania
  • Dodatkowo SolarWinds wymienia 2× „High” (m.in. hardcoded credentials) w tym samym wydaniu poprawek.
  • Rekomendowana poprawka: aktualizacja do WHD 2026.1; według Rapid7 podatne są wersje 12.8.8 Hotfix 1 i niższe.
  • Na 28 stycznia 2026 Rapid7 nie potwierdza „in-the-wild exploitation” dla tych nowych CVE, ale podkreśla historyczne zainteresowanie atakujących WHD.

Kontekst / historia / powiązania

Web Help Desk ma już „historię” podatności o wysokiej wadze, a to istotnie zmienia ocenę ryzyka: nawet jeśli nowa kampania nie jest jeszcze publicznie potwierdzona, to produkt był wcześniej atrakcyjnym celem.

  • Rapid7 wskazuje, że WHD pojawiał się w przeszłości na liście CISA Known Exploited Vulnerabilities (KEV).
  • BleepingComputer przypomina również o wcześniejszych obejściach poprawek oraz o przypadkach, gdy CISA wskazywała podatności WHD jako wykorzystywane w atakach.

Wniosek praktyczny: dla systemów helpdesk/ITSM ryzyko jest podwójne, bo poza przejęciem serwera atakujący często zyskuje też dostęp do bazy zgłoszeń, integracji, załączników oraz danych o infrastrukturze.

Analiza techniczna / szczegóły luki

CVE-2025-40551 oraz CVE-2025-40553 – RCE przez deserializację (unauth)

To klasyczny i groźny wzorzec: aplikacja deserializuje dane pochodzące od klienta, które nie są odpowiednio walidowane. Skutkiem może być zdalne wykonanie kodu / komend systemowych na hoście, i to bez uwierzytelnienia.

Z perspektywy obrońcy najgorsze elementy tego scenariusza to:

  • brak potrzeby posiadania konta,
  • potencjalnie „wysoka niezawodność” exploitacji typowa dla klas deserializacji (gdy istnieje odpowiedni łańcuch gadżetów),
  • szybkie uzbrajanie PoC, gdy detale techniczne trafią do obiegu.

CVE-2025-40552 oraz CVE-2025-40554 – obejście uwierzytelniania

Te dwie podatności opisano jako auth bypass, umożliwiający zdalnemu, nieuwierzytelnionemu atakującemu wykonywanie akcji/metod, które powinny być chronione logowaniem.

Co ważne, Rapid7 zwraca uwagę, że ocena CVSS sugeruje wpływ zbliżony do RCE – czyli w praktyce auth bypass może być ścieżką do wykonania kodu (np. przez wywołanie „nie tego” endpointu/akcji, która finalnie prowadzi do uruchomienia komendy lub deserializacji).

Dodatkowe „High” w pakiecie poprawek

Wydanie 2026.1 adresuje też m.in.:

  • CVE-2025-40536 – bypass kontroli bezpieczeństwa (8.1)
  • CVE-2025-40537 – hardcoded credentials (7.5), które w pewnych warunkach mogą ułatwiać dostęp do funkcji administracyjnych.

Praktyczne konsekwencje / ryzyko

Jeśli WHD jest osiągalny z sieci atakującego (Internet, sieć partnera, płaska sieć LAN, źle zabezpieczony VPN), typowy łańcuch skutków wygląda tak:

  • Przejęcie serwera WHD (RCE) → trwałość (webshell/usługa) → kradzież danych i ruch boczny
  • Dostęp do danych operacyjnych: zgłoszenia, dane użytkowników, integracje, tokeny, załączniki (często zawierające konfiguracje, logi, zrzuty ekranów, a czasem nawet hasła/API keys)
  • Możliwość użycia helpdesku do eskalacji organizacyjnej: podszywanie się, resetowanie haseł, manipulacja procesami wsparcia.

Podkreślmy: nawet jeśli „na dziś” (28 stycznia 2026) nie ma potwierdzonej masowej eksploatacji tych nowych CVE, historia WHD i jego typowa rola w firmie powodują, że to przypadek „patch fast”.

Rekomendacje operacyjne / co zrobić teraz

Priorytet 1: aktualizacja

  • Zaktualizuj do SolarWinds Web Help Desk 2026.1 (to wersja zawierająca poprawki dla CVE-2025-40551/40552/40553/40554).
  • Jeśli nie masz pewności, czy jesteś w grupie ryzyka: Rapid7 wskazuje, że podatne są 12.8.8 Hotfix 1 i niższe.

Priorytet 2: ograniczenie ekspozycji (gdy patchowanie nie jest natychmiast możliwe)

  • Zdejmij WHD z Internetu (jeśli jest publiczny) i wystawiaj wyłącznie przez VPN / ZTNA.
  • Ogranicz dostęp do panelu WHD na firewallu (allowlist IP, segmentacja).
  • Wymuś dodatkową warstwę uwierzytelniania przed WHD (reverse proxy + MFA), o ile architektura na to pozwala.

Priorytet 3: weryfikacja potencjalnej kompromitacji

  • Przejrzyj logi serwera aplikacji i reverse proxy pod kątem nietypowych żądań, błędów serializacji, podejrzanych sekwencji wywołań endpointów oraz anomalii czasowych.
  • Sprawdź, czy na hoście nie pojawiły się nowe pliki/artefakty (webshelle, nietypowe JAR/WAR, zadania harmonogramu, nowe usługi).
  • Jeśli WHD przechowuje/wykorzystuje sekrety (integracje, SMTP, API), rozważ rotację tych poświadczeń po aktualizacji.

Różnice / porównania z innymi przypadkami

W porównaniu do „typowych” podatności webowych (np. XSS/CSRF), obecny zestaw CVE jest groźniejszy z dwóch powodów:

  1. Brak uwierzytelnienia w ścieżkach prowadzących do RCE i wykonywania akcji uprzywilejowanych.
  2. Powtarzalność problemów w WHD (wcześniejsze obejścia poprawek, wzmianki o KEV i aktywnym wykorzystywaniu innych luk) – co w praktyce oznacza, że środowiska z WHD powinny być traktowane jak „wysoki priorytet” w backlogu podatności.

Podsumowanie / kluczowe wnioski

  • SolarWinds załatał w WHD cztery krytyczne luki (CVSS 9.8): dwie prowadzące do unauth RCE przez deserializację, dwie to auth bypass z potencjalnie porównywalnym wpływem.
  • Docelowa akcja: aktualizacja do WHD 2026.1 i potraktowanie jej jako pilnej, zwłaszcza jeśli WHD jest szeroko dostępny w sieci.
  • Nawet bez potwierdzonej eksploatacji „tu i teraz”, WHD jest produktem, który bywał celem ataków w przeszłości – dlatego warto równolegle wykonać kontrolę bezpieczeństwa po stronie hosta i logów.

Źródła / bibliografia

  • SolarWinds (release notes): WHD 2026.1 – lista naprawionych CVE, w tym CVE-2025-40551/40552/40553/40554 (documentation.solarwinds.com)
  • BleepingComputer: omówienie poprawek i kontekstu historycznego WHD (BleepingComputer)
  • Rapid7 (ETR): podsumowanie techniczne, wersje podatne, stan eksploatacji (Rapid7)
  • NVD: karta CVE-2025-40551 (opis, wektor CVSS 3.1, CWE-502) (NVD)
  • CISA KEV Catalog (wzmianka o wcześniejszej pozycji dot. SolarWinds WHD / hardcoded credential) (CISA)

Mustang Panda (HoneyMyte) rozwija CoolClient: nowe moduły kradzieży danych z przeglądarek i monitor schowka

Wprowadzenie do problemu / definicja luki

Chińsko-powiązana grupa szpiegowska znana jako Mustang Panda (w nomenklaturze części dostawców także HoneyMyte / Earth Preta / Bronze President) zaktualizowała swój backdoor CoolClient tak, aby skuteczniej wspierał kradzież danych uwierzytelniających i „życie z zasobów” (LOTL) w środowiskach ofiar. Najważniejsza zmiana: CoolClient nie jest już wyłącznie furtką do zdalnego dostępu, ale stał się platformą do wdrażania infostealerów (kradzież logowań z przeglądarek) oraz monitorowania schowka i aktywnego okna.

W skrócie

  • Nowy CoolClient potrafi monitorować schowek i śledzić tytuły aktywnych okien, a także podsłuchiwać poświadczenia do proxy HTTP.
  • W kampaniach zaobserwowano trzy rodziny stealerów: pod Chrome, Edge oraz wariant „uniwersalny” dla przeglądarek Chromium.
  • Eksfiltracja danych (np. cookies) może wykorzystywać legalne usługi (np. Google Drive) i tokeny/API wbudowane w operacje, co utrudnia detekcję po samym „dokąd wychodzi ruch”.
  • Cele kampanii to m.in. instytucje rządowe w kilku krajach Azji oraz poza nią (m.in. Myanmar, Mongolia, Malezja, Rosja, Pakistan).

Kontekst / historia / powiązania

CoolClient jest kojarzony z Mustang Panda co najmniej od 2022 r. i bywał wdrażany jako dodatkowa furtka obok innych znanych implantów tej klasy (np. PlugX, LuminousMoth).
Z perspektywy „rodziny” aktora warto pamiętać, że różni dostawcy opisywali go pod wieloma nazwami (np. Earth Preta), a kampanie często opierały się o spreparowane archiwa-przynęty i klasyczny spear-phishing.
W 2025 r. IBM X-Force wskazywał na szeroki arsenał i nakładające się klastry aktywności przypisywane temu ekosystemowi (m.in. ToneShell/Pubload oraz nowe techniki dystrybucji), co dobrze tłumaczy, dlaczego CoolClient jest dziś „rozbudowywany” zamiast zastępowany.

Analiza techniczna / szczegóły luki

1) Łańcuch uruchomienia i wieloetapowość (.DAT)

Z obserwacji badaczy wynika, że CoolClient korzysta z zaszyfrowanych plików .DAT i wieloetapowego wykonania. W opisie Kaspersky widoczny jest schemat, w którym implant:

  • odszyfrowuje kolejne artefakty (np. time.dat, loader.dat, main.dat),
  • uruchamia proces-pośrednik (write.exe) i wstrzykuje do niego kolejny etap,
  • buduje trwałość przez Run key, usługę systemową oraz zaplanowane zadanie.

2) Utrzymanie uprawnień i „passuac”

Warianty widziane w terenie wspierają obejście UAC i eskalację: przy sprzyjających warunkach uruchamiany jest tryb „passuac”, a następnie ustawiana jest trwałość przez zadanie harmonogramu.

3) Nowe funkcje: schowek, aktywne okno, sniffing proxy

Nowością w aktualnych wariantach jest:

  • monitor schowka (m.in. poprzez typowe API systemowe używane przez clipboard stealery),
  • telemetria aktywnego okna (np. tytuł okna),
  • HTTP proxy credential sniffer oparty o inspekcję pakietów i ekstrakcję nagłówków.

4) Ekosystem pluginów i zdalna powłoka

CoolClient utrzymuje architekturę z pluginami ładowanymi w pamięci, rozszerzoną m.in. o:

  • plugin zdalnej powłoki (ukryty cmd.exe, I/O przez potoki),
  • plugin zarządzania usługami (enumeracja, start/stop, modyfikacje),
  • rozbudowany plugin menedżera plików (mapowanie dysków sieciowych, kompresja ZIP, wyszukiwanie, uruchamianie plików).

5) Infostealery: Chrome/Edge/Chromium i eksfiltracja „przez legalne chmury”

W operacjach udokumentowano wdrażanie stealerów kradnących loginy z przeglądarek (różne warianty pod Chrome, Edge i Chromium-based).
Co istotne operacyjnie: w części przypadków eksfiltracja (np. pliki cookies) była wykonywana narzędziowo (np. przez curl) do legalnych usług typu Google Drive, z użyciem tokenów/kluczy wbudowanych w działania aktora, co utrudnia prostą blokadę na podstawie „złośliwej domeny”.

6) Dystrybucja: legalne oprogramowanie i DLL sideloading

BleepingComputer (na bazie ustaleń Kaspersky) wskazuje, że w obserwowanych atakach malware bywał wdrażany przez legalne komponenty związane z Sangfor, a wcześniej operatorzy uruchamiali CoolClient przez DLL side-loading z wykorzystaniem podpisanych binariów (np. popularne aplikacje użytkowe).

Uwaga „na radar”: badacze sygnalizują także użycie nieopisanego wcześniej rootkita w powiązaniu z tym zestawem narzędzi, ale szczegóły mają zostać opublikowane w osobnym raporcie.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości: kradzież haseł/cookies/sesji z przeglądarek to ryzyko przejęcia dostępu do poczty, SSO, paneli administracyjnych i narzędzi chmurowych.
  • Trudniejsza detekcja na poziomie sieci: eksfiltracja przez popularne legalne usługi (np. Google Drive) może „zniknąć w szumie” i wyglądać jak typowy ruch biznesowy.
  • Wysokie ryzyko post-exploitation: pluginy (shell, zarządzanie usługami, operacje na plikach) i techniki eskalacji/UAC sprzyjają długiej obecności w sieci i lateral movement.

Rekomendacje operacyjne / co zrobić teraz

  1. Ochrona poświadczeń i sesji
  • Włącz/egzekwuj MFA odporne na phishing (FIDO2/WebAuthn) dla kont uprzywilejowanych i dostępu do krytycznych SaaS.
  • Rotuj hasła i unieważnij sesje tam, gdzie wykryto anomalie przeglądarkowe (cookies/tokens).
  1. Detekcja na endpointach (EDR)
  • Poluj na nietypowe uruchomienia i wstrzyknięcia z udziałem procesów typu write.exe oraz aktywności wokół zaszyfrowanych .dat i nietypowych usług/zadań harmonogramu.
  • Monitoruj wywołania związane ze schowkiem oraz pobieranie danych logowania z profili przeglądarek (szczególnie w kontekście narzędzi typu curl).
  1. Kontrola ruchu do usług chmurowych
  • Nie blokuj „w ciemno” Google Drive, ale wdrażaj CASB / DLP / polityki uploadu dla stacji i kont uprzywilejowanych (kto, co i skąd wysyła pliki).
  • W proxy/secure web gateway ustaw alerty na masowe uploady i podejrzane nagłówki autoryzacji w nietypowych kontekstach (np. curl na stacjach użytkowników).
  1. Higiena oprogramowania i odporność na sideloading
  • Ogranicz uruchamianie nieautoryzowanych binariów (AppLocker/WDAC), zwłaszcza z katalogów użytkownika i ścieżek tymczasowych.
  • Waliduj łańcuch dostaw: jeśli w środowisku jest oprogramowanie wykorzystywane do „legitymizacji” uruchomienia, przejrzyj modele dystrybucji i podpisy/hashe.

Różnice / porównania z innymi przypadkami

W wielu kampaniach APT backdoor służy głównie do zdalnego sterowania i pobierania kolejnych modułów. Tu widać przesunięcie akcentu: CoolClient staje się platformą do kradzieży tożsamości (infostealery, schowek, proxy sniffing) oraz do eksfiltracji „pod przykrywką” legalnych usług.
Na tle wcześniejszych opisów Earth Preta/Mustang Panda (phishing, archiwa-przynęty, szeroki arsenał) to spójna ewolucja: mniej hałaśliwe domeny C2 w warstwie eksfiltracji, większy nacisk na dostęp przez konta i sesje.

Podsumowanie / kluczowe wnioski

CoolClient w najnowszych kampaniach Mustang Panda/HoneyMyte to już nie tylko „backdoor”, ale modułowa platforma post-exploitation z funkcjami typowymi dla wyspecjalizowanych złodziei danych (schowek, przeglądarki, proxy) i z mechanizmami utrzymania dostępu (usługi, taski, obejście UAC). Priorytet obrony powinien przesunąć się na ochronę tożsamości (MFA/FIDO2), telemetry EDR wokół przeglądarek i narzędzi transferu, oraz kontrolę uploadów do legalnych chmur.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i podsumowanie zmian w CoolClient (27 stycznia 2026). (BleepingComputer)
  2. Kaspersky Securelist (GReAT) – analiza techniczna CoolClient i stealerów (27 stycznia 2026). (Securelist)
  3. Trend Micro – tło dot. Earth Preta/Mustang Panda i taktyk kampanii (2023). (www.trendmicro.com)
  4. IBM X-Force – kontekst dot. Hive0154/Mustang Panda, arsenału i technik dystrybucji (2025). (IBM)

WinRAR: podatność path traversal CVE-2025-8088 nadal masowo wykorzystywana — jak działa łańcuch ataku i co zrobić teraz

Wprowadzenie do problemu / definicja luki

CVE-2025-8088 to podatność typu path traversal w WinRAR dla Windows, która pozwala atakującym zapisać pliki poza katalogiem wskazanym przez użytkownika podczas rozpakowywania. W praktyce oznacza to możliwość „podrzucenia” złośliwego pliku w lokalizacji uruchamianej automatycznie (np. Windows Startup) i uzyskania wykonania kodu przy spełnieniu warunku interakcji użytkownika (otwarcie/rozpakowanie spreparowanego archiwum).

Co ważne: chociaż poprawka jest dostępna od lipca 2025, najnowsze raporty pokazują, że luka jest nadal intensywnie wykorzystywana przez wiele grup — od aktorów państwowych po cyberprzestępców „commodity”.

W skrócie

  • Co to jest: path traversal w WinRAR/UnRAR na Windows (CWE-35).
  • Jak jest wykorzystywane: przez Alternate Data Streams (ADS) na NTFS do ukrycia i wypakowania payloadu w niezamierzone miejsce (często Startup).
  • Kogo dotyczy: WinRAR/UnRAR i komponenty na Windows (m.in. UnRAR.dll) — platformy Linux/Unix i Android nie są dotknięte.
  • Status: aktywna eksploatacja obserwowana od 18 lipca 2025 i nadal trwająca (raporty z 27 stycznia 2026).
  • Mitigacja: aktualizacja do WinRAR 7.13+ oraz przegląd zależności (UnRAR.dll) w innych produktach.

Kontekst / historia / powiązania

Podatność została wykryta i zgłoszona przez badaczy ESET, a WinRAR opublikował poprawkę w linii 7.13 (wersja final 30.07.2025; notki aktualizowane 12.08.2025).

W styczniu 2026 Google Threat Intelligence Group (GTIG) opisał problem jako klasyczny przykład „n-day”, który mimo dostępnej łatki pozostaje skuteczny, bo:

  • użytkownicy często nie aktualizują WinRAR (brak automatycznych aktualizacji w typowych wdrożeniach),
  • a wektor „archiwum + socjotechnika” jest tani i powtarzalny dla wielu grup.

Analiza techniczna / szczegóły luki

Mechanizm: path traversal + ADS (NTFS)

CVE-2025-8088 wykorzystuje Alternate Data Streams (ADS) — cechę NTFS pozwalającą dołączać „strumienie” danych do pliku w sposób mało widoczny dla użytkownika. Atakujący przygotowuje archiwum tak, aby zawierało plik-przynętę (np. dokument), a właściwy payload był ukryty w ADS.

Następnie, podczas podglądu/otwarcia pliku z archiwum lub rozpakowywania, WinRAR:

  1. rozpakowuje plik-przynętę (żeby ofiara widziała „normalny” dokument),
  2. równolegle rozpakowuje ADS-y, a dzięki obejściu ścieżki docelowej może je zrzucić poza wybrany katalog.

Typowe payloady i post-exploitation

W obserwowanych kampaniach wypakowywane były m.in. LNK, HTA, BAT, CMD i inne skrypty/artefakty, które uruchamiają kolejne etapy infekcji (np. przy logowaniu). Szczególnie atrakcyjny jest zrzut do Windows Startup folder — daje to persistence „bez fajerwerków”.

Ocena ryzyka (NVD)

NVD opisuje podatność jako umożliwiającą wykonanie dowolnego kodu po spreparowaniu archiwum i interakcji użytkownika; wektor CVSS v3.1 wskazuje m.in. UI:R (wymagana akcja użytkownika), ale z pełnym wpływem na poufność/integralność/dostępność.

Praktyczne konsekwencje / ryzyko

Największe ryzyko wynika z połączenia trzech czynników:

  1. Masowość: raporty z 27.01.2026 mówią o wielu aktorach i różnych ładunkach (od RAT-ów po stealery).
  2. „Niewidzialność” dla użytkownika: ofiara widzi poprawny dokument, a złośliwe ADS-y są „w tle”.
  3. Persistence bez exploitów kernelowych: zrzut do Startup daje trwałość po restarcie/logowaniu.

GTIG wskazuje, że oprócz grup powiązanych z państwami (m.in. obserwowane operacje przypisywane aktorom powiązanym z Rosją/Chinami), podatność jest wykorzystywana także przez cyberprzestępców do dystrybucji popularnych narzędzi zdalnego dostępu i stealerów (np. AsyncRAT, XWorm).

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacja i inwentaryzacja (najważniejsze)

  • Zaktualizuj WinRAR do 7.13 lub nowszej.
  • Zidentyfikuj, gdzie w organizacji występują komponenty UnRAR.dll / UnRAR (często są „zagnieżdżone” w innych aplikacjach, instalatorach, narzędziach backupowych) i zaktualizuj zależności.

2) Ogranicz skutki socjotechniki

  • Blokuj/izoluj archiwa z nieznanych źródeł (brama mailowa, sandbox).
  • Wrażliwe zespoły (finanse, HR, logistyka, zarząd) — dodatkowe reguły dla załączników RAR/ZIP, zwłaszcza w kampaniach spearphishing. (To wpisuje się w obserwowany model ataku opisany przez ESET/GTIG).

3) Hardening punktów uruchomieniowych

  • Monitoruj i ogranicz możliwość zapisu do lokalizacji persistence, w szczególności ścieżek powiązanych z Startup.
  • Zaostrz polityki uruchamiania dla LNK/HTA/skryptów z katalogów użytkownika i TEMP (SRP/AppLocker/WDAC — zależnie od środowiska).

4) Detekcja i hunting

  • Wykorzystaj informacje i IOCs opublikowane przez GTIG do polowań (jeśli prowadzisz threat hunting / SOC).
  • Koreluj zdarzenia: rozpakowanie archiwum → powstanie plików typu LNK/HTA/BAT/CMD w nietypowych ścieżkach → uruchomienie przy logowaniu.

Różnice / porównania z innymi przypadkami

WinRAR podkreśla, że CVE-2025-8088 jest odrębna od wcześniejszej podatności naprawionej w 7.12.
ESET dodatkowo wskazuje podobną podatność path traversal CVE-2025-6218 ujawnioną około miesiąc wcześniej (czerwiec 2025), co pokazuje, że klasa błędów w obsłudze ścieżek i archiwów była w tym okresie szczególnie „gorąca” i atrakcyjna dla atakujących.

Podsumowanie / kluczowe wnioski

  • CVE-2025-8088 to praktyczny, „wdzięczny” exploit chain: archiwum + ADS + path traversal → zrzut do Startup → persistence → dalsza infekcja.
  • Najnowsze dane (27.01.2026) potwierdzają ciągłą eksploatację przez szeroki przekrój aktorów.
  • Największym problemem nie jest brak patcha, tylko opóźnione aktualizacje i „ukrycie” zależności (UnRAR.dll) w innych produktach.

Źródła / bibliografia

  1. BleepingComputer — „WinRAR path traversal flaw still exploited by numerous hackers” (27.01.2026). (BleepingComputer)
  2. Google Threat Intelligence Group — „Diverse Threat Actors Exploiting Critical WinRAR Vulnerability CVE-2025-8088” (27.01.2026). (Google Cloud)
  3. NVD (NIST) — wpis podatności CVE-2025-8088. (NVD)
  4. RARLAB / win-rar.com — „WinRAR 7.13 Final released” (release notes + zakres wpływu). (WinRAR download free and support)
  5. ESET WeLiveSecurity — „Update WinRAR tools now: RomCom and others exploiting zero-day vulnerability” (analiza ADS i timeline). (welivesecurity.com)

Ponad 6 tys. serwerów SmarterMail narażonych na automatyczne przejęcia kont admina (CVE-2026-23760)

Wprowadzenie do problemu / definicja luki

SmarterMail (serwer pocztowy i platforma współpracy od SmarterTools) znalazł się na celowniku masowych, zautomatyzowanych ataków po ujawnieniu krytycznej luki CVE-2026-23760. Błąd pozwala bez uwierzytelnienia przejąć konto administratora poprzez nieprawidłowo zaprojektowane API resetu hasła, a następnie – dzięki wbudowanym funkcjom administracyjnym – doprowadzić do zdalnego wykonania poleceń na hoście (RCE).

Równolegle organizacje typu Shadowserver raportowały tysiące instancji wystawionych do internetu, które wyglądały na podatne, a analitycy obserwowali już ataki „in the wild”.

W skrócie

  • CVE-2026-23760: obejście uwierzytelnienia w API resetu hasła; dotyczy wersji przed build 9511.
  • Wektor: POST /api/v1/auth/force-reset-password akceptuje żądania anonimowe i w krytycznej ścieżce dla sysadmina nie weryfikuje starego hasła / tokenu resetu.
  • Skutek: przejęcie konta admina → szybka eskalacja do RCE/SYSTEM przez funkcje administracyjne (np. wykonywanie komend).
  • Eksploatacja była obserwowana masowo i automatycznie (sekwencje żądań API, tworzenie „System Events”, sprzątanie śladów).
  • Skala: raportowano >6 000 publicznie dostępnych serwerów potencjalnie narażonych.

Kontekst / historia / powiązania

CVE-2026-23760 wypłynęło krótko po innej krytycznej luce w SmarterMail (CVE-2025-52691), co podbiło zainteresowanie atakujących (i presję na zespoły IT). BleepingComputer opisał sytuację jako serię zdarzeń: zgłoszenie, szybka poprawka, a następnie szybka adaptacja eksploitu i skanowanie internetu w poszukiwaniu podatnych serwerów.

Istotny kontekst operacyjny: w przypadku serwerów pocztowych ekspozycja na internet jest często „z definicji” (webmail, panel admina, API), więc okno czasowe między patchem a masową eksploatacją bywa wyjątkowo krótkie. SecurityWeek cytował watchTowr, że poprawka została szybko przeanalizowana (reverse engineering) i zaczęła być wykorzystywana na szeroką skalę.

Analiza techniczna / szczegóły luki

1) Root cause: reset hasła admina bez dowodu tożsamości

watchTowr opisał problem jako błąd w logice resetu hasła: endpoint force-reset-password jest dostępny anonimowo (co samo w sobie bywa normalne dla resetów), ale ścieżka dla kont sysadmin pozwala podać Username i NewPassword bez weryfikacji OldPassword lub tokenu resetu.

W praktyce: jeśli atakujący zna (lub zgadnie) nazwę konta administratora (często „admin”), może zresetować hasło i zalogować się jako administrator.

2) Od przejęcia konta do RCE – dwie obserwowane ścieżki

  • Ścieżka A (watchTowr): po przejęciu sysadmina możliwe jest doprowadzenie do wykonania poleceń systemowych przez wbudowane funkcje administracyjne (watchTowr opisał drogę przez ustawienia i mechanizm, który finalnie uruchamia komendę na hoście).
  • Ścieżka B (Huntress): w atakach „in the wild” widziano użycie funkcji System Events – napastnik po zdobyciu tokena dostępu tworzył złośliwy event-hook, wyzwalał go (np. dodaniem domeny), a potem wykonywał działania porządkowe (kasowanie domeny i hooka).

3) Sygnały masowej automatyzacji

Huntress pokazał typową sekwencję żądań API obserwowaną u wielu ofiar w krótkich odstępach czasu (co wygląda na automatyczne skrypty), zaczynając od wymuszenia resetu hasła, potem autoryzacji i konfiguracji mechanizmów do wykonania komend.

Praktyczne konsekwencje / ryzyko

Przejęty serwer SmarterMail to zwykle „klucz do królestwa” poczty:

  • dostęp do skrzynek, korespondencji i danych wrażliwych,
  • możliwość podszywania się (phishing/BEC), reguły przekierowań, utrwalanie dostępu,
  • infrastruktura do dalszych ataków (malware, pivot w sieci, kradzież poświadczeń),
  • ryzyko incydentu zgodności (RODO), reputacji i ciągłości działania.

NVD wprost wskazuje, że uprawnienia sysadmina w SmarterMail mogą przekładać się na administracyjne uprawnienia na hoście (SYSTEM/root) dzięki wbudowanym funkcjom zarządzania – co z perspektywy IR oznacza traktowanie takiego zdarzenia jak pełne przejęcie serwera.

Rekomendacje operacyjne / co zrobić teraz

1) Patch i weryfikacja wersji

  • Zaktualizuj do build 9511 lub nowszego (wszystko „przed 9511” jest wprost wskazywane jako podatne).

2) Jeśli nie możesz zaktualizować natychmiast (awaryjnie)

  • ogranicz dostęp do panelu/web API (VPN/allowlista IP, przynajmniej dla interfejsu administracyjnego),
  • rozważ tymczasowe reguły reverse proxy/WAF ograniczające dostęp do ścieżek API resetu hasła (uwaga: to obejście, nie „fix”),
  • włącz monitoring anomalii na endpointach /api/v1/auth/* i akcjach administracyjnych.

3) „Assume breach” – szybkie polowanie i IR

Szukaj w logach (proxy / aplikacyjnych) nietypowych żądań:

  • POST /api/v1/auth/force-reset-password oraz dalszych sekwencji API,
  • tworzenia/edycji System Events / event-hooków i operacji dodania/usunięcia domen (pattern z Huntress).

IOCs/sygnały (wg Huntress):

  • powtarzające się, szybkie sekwencje żądań API,
  • user-agent python-requests/2.32.4 widziany w atakach,
  • artefakt plikowy wskazywany w analizie Huntress (plik z wynikami rozpoznania).

4) Higiena po incydencie

  • reset haseł kont uprzywilejowanych (i rotacja kluczy/sekretów, jeśli serwer miał dostęp do innych systemów),
  • przegląd reguł przekazywania poczty, integracji i webhooków,
  • sprawdzenie trwałości (scheduled tasks, usługi, web-shelle, nieznane binaria),
  • segmentacja i minimalizacja ekspozycji usług zarządzających.

Różnice / porównania z innymi przypadkami

Warto odróżnić dwie głośne luki SmarterMail z przełomu stycznia:

  • CVE-2026-23760 – „czyste” przejęcie admina przez reset hasła bez weryfikacji (API), a potem RCE jako konsekwencja uprawnień admina i funkcji administracyjnych.
  • CVE-2025-52691 – wcześniejsza, krytyczna podatność pre-auth (opisywana jako droga do RCE na niezałatanych serwerach), wspominana w kontekście tej fali ataków.

Operacyjnie: w CVE-2026-23760 kluczowe jest, że atakujący może „wejść drzwiami frontowymi” jako admin (zmieniając hasło), co utrudnia detekcję, jeśli organizacja monitoruje wyłącznie klasyczne wskaźniki exploitów RCE.

Podsumowanie / kluczowe wnioski

  • CVE-2026-23760 to krytyczny błąd projektowy w API resetu hasła, który umożliwia przejęcie konta sysadmina i w praktyce prowadzi do pełnego kompromisu serwera.
  • Skala ekspozycji jest duża (tysiące instancji wystawionych do internetu), a eksploatacja była obserwowana jako zautomatyzowana.
  • Najważniejsze działania: aktualizacja do build 9511+, ograniczenie ekspozycji panelu/API oraz szybkie threat hunting pod kątem sekwencji API i nadużyć System Events.

Źródła / bibliografia

  • BleepingComputer – o skali ekspozycji i trwających atakach (BleepingComputer)
  • NVD (NIST) – opis CVE-2026-23760, wersje podatne, charakter wpływu (NVD)
  • watchTowr Labs – analiza techniczna root cause i PoC dla force-reset-password (watchTowr Labs)
  • Huntress – obserwacje ataków „in the wild”, sekwencje API i IOCs (Huntress)
  • SecurityWeek – kontekst masowej eksploatacji i mechaniki nadużyć (SecurityWeek)