Archiwa: AI - Strona 163 z 176 - Security Bez Tabu

Tag: AI

Złośliwe „skills” dla OpenClaw/MoltBot: nowy wektor ataku łańcucha dostaw i kradzieży haseł

Wprowadzenie do problemu / definicja luki

W ekosystemie self-hosted agentów AI pojawił się klasyczny problem supply chain — tyle że zamiast paczek npm/PyPI, celem stały się „skills” (wtyczki/pakiety funkcjonalności) dla osobistego asystenta AI OpenClaw (wcześniej: Moltbot/ClawdBot). Atakujący masowo publikują „skills” udające narzędzia (np. do krypto, finansów, social mediów), a w praktyce służące do instalacji infostealerów i kradzieży danych uwierzytelniających.

W skrócie

  • W krótkim oknie czasu (ok. 27 stycznia – 1 lutego 2026) opublikowano setki podejrzanych/złośliwych „skills” w rejestrze ClawHub i na GitHub.
  • Infekcja zwykle wymaga, by ofiara ręcznie wykonała instrukcje z dokumentacji („Prerequisites”), co przypomina schemat ClickFix: użytkownik sam uruchamia polecenie/pobiera narzędzie, bo „jest potrzebne do działania”.
  • Na macOS w łańcuchu pojawia się m.in. zdejmowanie atrybutu kwarantanny (xattr -c) w celu obejścia mechanizmów typu Gatekeeper oraz kradzież danych z pęku kluczy i profili przeglądarek.
  • Niezależnie od szczegółów payloadu, kluczowy problem jest systemowy: agent AI działa lokalnie i ma „głębokie” uprawnienia, a „skills” są w praktyce kodem wykonywalnym.

Kontekst / historia / powiązania

OpenClaw/MoltBot stał się wiralowy jako „personal AI agent” uruchamiany lokalnie, z pamięcią długoterminową i integracjami z usługami (komunikatory, e-mail, pliki, automatyzacje). Taka architektura jest atrakcyjna, ale z perspektywy bezpieczeństwa oznacza, że kompromitacja ekosystemu rozszerzeń jest kompromitacją hosta i danych użytkownika. Cisco zwraca uwagę, że narzędzia tego typu potrafią automatyzować działania, uruchamiać skrypty i operować na zasobach, co znacząco podnosi stawkę przy błędach w modelu uprawnień i dystrybucji rozszerzeń.

Równolegle pojawia się drugi wątek: poza zatruciem marketplace’u „skills”, badacze i źródła threat-intel wskazują też na błędnie wystawione interfejsy administracyjne oraz ryzyka wynikające z przechowywania sekretów w plikach i zdalnej ekspozycji usług.

Analiza techniczna / szczegóły luki

1) Mechanizm dystrybucji: „skills” jako nośnik zaufanego kodu

„Skills” są opisywane jako łatwo wdrażalne wtyczki/rozszerzenia. W praktyce atak polega na tym, że publikowane paczki:

  • klonują się masowo (bliźniacze repozytoria, losowe nazwy),
  • mają dopracowaną dokumentację,
  • podszywają się pod narzędzia o wysokiej „wartości” dla ofiar (krypto, finanse, narzędzia produktywności).

2) Socjotechnika „Prerequisites” i fałszywe narzędzia („AuthTool” / „openclaw-agent”)

W opisywanych kampaniach kluczowy jest punkt „Prerequisites”. To tam użytkownik dostaje instrukcję:

  • na macOS: wkleić do terminala polecenie (często base64 → bash, z pobraniem skryptu/payloadu z zewnętrznego hosta),
  • na Windows: pobrać i uruchomić archiwum ZIP (często zaszyfrowane hasłem, co utrudnia automatyczne skanowanie).

Koi Security opisuje też, że ZIP z hasłem jest używany nie „dla bezpieczeństwa”, ale jako taktyka przeciwko automatycznym analizatorom i AV w pipeline’ach.

3) Payload i kradzież danych: macOS i Windows

Z perspektywy skutków, celem jest klasyczny infostealer:

  • BleepingComputer wskazuje na wariant NovaStealer na macOS, który potrafi m.in. zdejmować kwarantannę (xattr -c), żądać szerokiego dostępu do plików i wyciągać dane takie jak: klucze API giełd krypto, seed phrases, dane z rozszerzeń walletów, dane z Keychain, hasła przeglądarki, klucze SSH, poświadczenia chmurowe, Git credentials i pliki .env.
  • Koi Security w swojej analizie przypisuje główną falę do kampanii (nazwanej ClawHavoc) i identyfikuje macOS-owy stealer jako Atomic Stealer (AMOS), opisując charakterystyczny łańcuch (pobranie skryptu → dropper → uruchomienie binarki) oraz szeroki zakres kradzionych artefaktów (przeglądarki, portfele, SSH, komunikatory).

W praktyce możliwe są rozbieżności w klasyfikacji rodziny malware (NovaStealer vs AMOS), bo część zachowań/artefaktów może być współdzielona lub zmieniana w kolejnych wariantach — dla obrony ważniejsze jest rozpoznanie TTP: ręczne uruchamianie „prerekwizytów”, download z zewnętrznych domen/IP, zdejmowanie kwarantanny i masowa eksfiltracja sekretów.

4) Skala i dodatkowe techniki (typosquatting, outliery)

  • Audyt cytowany przez The Hacker News mówi o 341 złośliwych „skills” na ClawHub (na tle ~2,857 sprawdzonych), z dominującą kampanią i dodatkowymi odchyleniami.
  • Wskazano też typosquatting (warianty nazw związanych z ClawHub), co zwiększa skuteczność infekcji przy literówkach i instalacjach „na skróty”.

Praktyczne konsekwencje / ryzyko

Ten incydent jest groźny nie tylko przez samą liczbę złośliwych paczek, ale przez kontekst użycia:

  • Agent AI ma dostęp do plików, przeglądarki, tokenów, integracji z usługami i często działa „jak użytkownik” — z naturalną zdolnością do eskalacji skutków kompromitacji (np. dostęp do repozytoriów, CI/CD, e-maila).
  • Kradzież .env, kluczy API, SSH i poświadczeń chmurowych oznacza ryzyko przejęcia kont i infrastruktury, a nie tylko „wycieku haseł z przeglądarki”.
  • Jeśli instancje administracyjne są wystawione do internetu lub słabo zabezpieczone, dochodzi dodatkowa powierzchnia ataku: przejęcie zarządzania agentem lub wykorzystanie go jako backdoora.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” — w kolejności od najszybszych do bardziej systemowych:

1) Natychmiastowe ograniczenie ryzyka

  • Wstrzymaj instalację nowych „skills” z publicznych rejestrów w zespołach/firmie do czasu wdrożenia zasad weryfikacji.
  • Potraktuj „skill” jak binarkę: jeśli ktoś każe wkleić komendę do terminala albo pobrać „narzędzie wymagane do działania” — to czerwony alarm.
  • Jeżeli instalowano „skills” w ostatnich dniach: rotuj sekrety (API keys, tokeny, SSH, klucze do giełd), sprawdź logi dostępu i nietypowe logowania.

2) Walidacja i skanowanie

  • Weryfikuj publishera, historię repo, podobieństwa nazw, a także czy nie ma „Prerequisites” z obfuskacją (base64, curl|bash).
  • Skorzystaj z narzędzi do oceny „skills” publikowanych przez badaczy (np. skaner URL od Koi Security) jako dodatkowego sygnału, nie jedynego kontrolera.

3) Izolacja środowiska (najważniejsze przy agentach AI)

  • Uruchamiaj OpenClaw w VM/kontenerze z minimalnymi uprawnieniami i separacją od głównego profilu przeglądarki, kluczy SSH i repozytoriów (zasada najmniejszych uprawnień).
  • Ogranicz egress (firewall, allowlist domen), bo większość łańcuchów infekcji i eksfiltracji wymaga połączeń wychodzących.

4) Governance „skills” w organizacji

  • Wprowadź allowlist zatwierdzonych „skills”, wersjonowanie i pinning (konkretne commity/release), a docelowo podpisywanie/artefakty z kontrolą integralności.
  • Rozważ całkowite wyłączenie mechanizmu „skills”, jeśli nie potrafisz go kontrolować (SOC Prime wprost sugeruje rozważenie ograniczenia tej funkcji bez odpowiedniego nadzoru).

5) Detekcja i IR

  • Monitoruj: nietypowe procesy powłoki, curl/bash w kontekście instalacji, zdejmowanie kwarantanny (xattr -c), nowe binarki w katalogach tymczasowych, nietypowy ruch do nieznanych hostów.
  • Jeśli podejrzewasz kompromitację: izoluj host, zbierz artefakty, zresetuj poświadczenia, przeprowadź przegląd integracji agenta z usługami (mail, repo, kalendarze) i rozważ reinstalację w utwardzonym środowisku.

Różnice / porównania z innymi przypadkami

To zdarzenie wpisuje się w dobrze znany schemat:

  • marketplace/registry → masowe paczki → socjotechnika → payload (jak w atakach na npm/PyPI/VS Code). Koi Security wprost porównuje ClawHub do popularnych ekosystemów paczek, wskazując, że „tam gdzie deweloperzy dzielą się kodem, tam pojawiają się atakujący”.
  • Różnica jest taka, że tutaj ofiary instalują rozszerzenia dla narzędzia, które z założenia ma szeroki dostęp i automatyzuje działania, więc „blast radius” może być większy niż przy typowej wtyczce do IDE.

Podsumowanie / kluczowe wnioski

  • Publiczny ekosystem „skills” dla OpenClaw/MoltBot stał się celem masowego zatrucia łańcucha dostaw, a skutkiem jest dystrybucja infostealerów i kradzież sekretów.
  • Najczęstszy wektor to „Prerequisites” i ręczne uruchamianie poleceń/instalatorów (ClickFix-like), co omija część automatycznych kontroli.
  • Najskuteczniejsza obrona to połączenie: izolacji środowiska agenta, twardego governance rozszerzeń oraz szybkiej rotacji sekretów, jeśli instalacje już miały miejsce.

Źródła / bibliografia

  1. (BleepingComputer) – BleepingComputer: skala kampanii, „AuthTool”, ClickFix-like, NovaStealer i zakres kradzieży
  2. (koi.ai) – Koi Security: audyt 2,857 „skills”, 341 złośliwych, ClawHavoc, techniki i łańcuch macOS
  3. (The Hacker News) – The Hacker News: podsumowanie ustaleń Koi i kategorie kampanii na ClawHub
  4. (Cisco Blogs) – Cisco Blogs: ryzyka architektoniczne „personal AI agents” i konsekwencje braku sandboxingu/governance
  5. (SOC Prime) – SOC Prime: perspektywa threat-intel (ekspozycja admin portów, sekrety w plikach, mitigacje)

RedKitten: irańska kampania szpiegowska z „akceleracją AI” celuje w NGO i aktywistów

Wprowadzenie do problemu / definicja luki

Kampania RedKitten to świeżo zidentyfikowany łańcuch ataku, który wykorzystuje klasyczny wektor „dokument z makrem”, ale dokłada do niego dwie nowoczesne cechy: komodytyzację infrastruktury (usługi chmurowe i komunikatory zamiast własnych serwerów) oraz oznaki LLM-wspomaganego developmentu (styl kodu, komentarze, szybka iteracja). W praktyce to nie „jedna luka CVE”, tylko zestaw technik prowadzących do zdalnej kontroli i eksfiltracji danych.

Badacze HarfangLab opisują tę aktywność jako kampanię obserwowaną na początku stycznia 2026 r., wymierzoną w osoby i organizacje dokumentujące nadużycia praw człowieka.

W skrócie

  • Punkt startu: archiwum (m.in. 7z) z arkuszami XLSM zawierającymi złośliwe makra.
  • Dropper z makra uruchamia implant C# (w raporcie nazwany SloppyMIO) i wykorzystuje AppDomainManager injection jako technikę uruchomienia w kontekście .NET.
  • Konfiguracja i moduły są pobierane z legalnych usług: GitHub oraz Google Drive, a kanał C2 realizowany jest przez Telegram.
  • W infrastrukturze widoczne są elementy steganografii (konfiguracja osadzana w obrazach) oraz iteracyjny rozwój (zmiany w gistach, wersjonowanie).
  • Atrybucja: silne przesłanki na aktora farsi-języcznego powiązanego z interesami państwowymi Iranu, ale bez jednoznacznego przypisania do znanej grupy.

Kontekst / historia / powiązania

Wątek „kittens” to nie przypadek: w ekosystemie threat intel nazewnictwo wielu irańskich klastrów i grup często zawiera „Kitten”. Opisuje to m.in. Middle East Institute w przeglądzie irańskich APT i konwencji nazewniczych.

W tle warto też pamiętać o długiej historii irańskich działań ofensywnych, w tym operacji określanych jako Fox Kitten w bazie MITRE ATT&CK.
Z kolei raport ClearSky Cyber Security (2020) pokazuje, że część irańskich kampanii łączyła rozpoznanie i utrzymanie dostępu z gotowością do eskalacji (np. do działań destrukcyjnych) oraz wykorzystywała szeroką infrastrukturę i dostęp przez zewnętrzne usługi zdalne.

Analiza techniczna / szczegóły luki

1) Initial access: XLSM + makra + socjotechnika

Atak startuje od dokumentów XLSM podszywających się pod materiały związane z ofiarami protestów (tematyka „shock lures”).
W opisie The Hacker News podkreślono oznaki generowania lub wspomagania kodu VBA przez LLM (styl, nazewnictwo, komentarze typu „PART …”).

2) Execution: AppDomainManager injection (w praktyce: .NET-owe „hijackowanie” ładowania)

Makro działa jako dropper dla implantu C# i wykorzystuje technikę AppDomainManager injection.
Z perspektywy obrony to istotne, bo AppDomainManager może umożliwiać wykonanie arbitralnego kodu w procesie .NET poprzez kontrolę sposobu ładowania domen aplikacji i assembly. Dobre omówienie mechaniki i tropów detekcyjnych opisuje Pentest Laboratories.

3) Implant i moduły: SloppyMIO jako „mini-framework” z pobieraniem funkcji na żądanie

W raporcie HarfangLab implant SloppyMIO:

  • cyklicznie odświeża konfigurację,
  • pobiera moduły (źródła .cs lub gotowe DLL),
  • buforuje je (cache) i uruchamia funkcje typu Run().

Wprost opisano też funkcje modułowe, m.in. wykonywanie poleceń, zbieranie plików i wysyłkę danych kanałem C2, z uwzględnieniem limitów rozmiaru wiadomości/dokumentów.

4) C2 i infrastruktura: „legit services only” + steganografia

Najbardziej charakterystyczny fragment tej kampanii to przeniesienie kluczowych elementów w legalne platformy:

  • dead drop/resolver na GitHub (gisty),
  • hostowanie modułów i obrazów na Google Drive,
  • sterowanie przez Telegram (bot token + chat ID w konfiguracji).

HarfangLab opisuje również wersjonowanie „steganographic configuration image” oraz timeline commitów gistów od października 2025 do 23 stycznia 2026 r., co sugeruje iteracyjne dopracowywanie narzędzia i (paradoksalnie) zostawia sporo metadanych.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla NGO / OSINT / aktywistów: kradzież dokumentacji, list kontaktów, materiałów dowodowych, metadanych (kto, kiedy, z kim).
  2. Ryzyko organizacyjne: kompromitacja skrzynek, komunikatorów i repozytoriów danych może prowadzić do deanonimizacji źródeł i działań odwetowych.
  3. Utrudnione blokowanie po IP/domenie: jeśli ruch idzie do usług powszechnie używanych (Drive/Telegram), polityka „po prostu zablokuj domenę” bywa nierealna.
  4. Próg wejścia spada: jeśli LLM realnie przyspiesza pisanie makr/loaderów i modułów, to tempo iteracji w kampaniach phishingowych może rosnąć (więcej wariantów, krótsze cykle).

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  • Zablokuj makra z Internetu w środowisku M365 (Attack Surface Reduction / Office policy) i ogranicz uruchamianie XLSM do zaufanych lokalizacji.
  • Hunting po artefaktach: w raporcie HarfangLab są IOC (hash’e), ścieżki oraz nazwy zaplanowanych zadań (scheduled tasks) i reguły YARA — warto je wciągnąć do procesu detekcji w EDR/SIEM.
  • Telemetria dla .NET: poluj na anomalie wokół AppDomainManager (np. nietypowe pliki konfiguracyjne, podejrzane assembly ładowane przez legalne binarki .NET) – technika bywa używana dla „cichego” wykonania.

Twardnienie i prewencja (1–4 tygodnie)

  • Segmentacja i kontrola egress: jeśli nie możesz zablokować Telegram/Drive globalnie, rozważ:
    • allowlistę procesów/hostów, które mogą rozmawiać z tymi usługami,
    • inspekcję DNS/HTTP(S) pod kątem nietypowych wzorców pobrań modułów.
  • Detekcja „living on popular services”: buduj reguły korelacyjne typu: uruchomienie Office → tworzenie DLL/artefaktów w profilu użytkownika → scheduled task → ruch do Drive/Telegram.
  • Szkolenia anty-phishingowe ukierunkowane na „dokumenty-pułapki” i scenariusze kryzysowe (lures o silnym ładunku emocjonalnym).

Różnice / porównania z innymi przypadkami

  • „Kitteny” różnią się tradecraftem: część historycznych kampanii skupiała się na utrzymaniu dostępu i eksploatacji usług zdalnych (VPN/RDP), co opisywał ClearSky w kontekście Fox Kitten.
  • RedKitten idzie mocno w „legit infra” i automatyzację: zamiast klasycznej infrastruktury C2 – Telegram + Drive + GitHub, do tego steganografia i modułowość.
  • Podobieństwa w „protest lures”: Kaspersky opisywał w 2021 r. kampanię Ferocious Kitten, która także wykorzystywała dokumenty-wabiki z makrami i tematy protestów, a nawet celowała w ekosystem komunikatorów.

Podsumowanie / kluczowe wnioski

  • RedKitten to kampania szpiegowska, która łączy stare dobre makra z nowoczesnym podejściem do infrastruktury (popularne usługi) i prawdopodobnym wsparciem LLM przy wytwarzaniu kodu.
  • Największym wyzwaniem obronnym jest nie sam dropper, tylko detekcja i blokowanie modularnego implantu korzystającego z Drive/Telegram bez wyraźnych „złych domen”.
  • Najbardziej praktyczny krok: twarda polityka dla makr + hunting po IOC/YARA + telemetria .NET pod kątem AppDomainManager.

Źródła / bibliografia

  1. HarfangLab – RedKitten: AI-accelerated campaign targeting Iranian protests (29 stycznia 2026). (HarfangLab)
  2. The Hacker News – opis kampanii i wskazówki dot. LLM-generowanych makr (31 stycznia 2026). (The Hacker News)
  3. MITRE ATT&CK – wpis o Fox Kitten (G0117) i kontekst grup powiązanych (aktualizacje do 2024). (attack.mitre.org)
  4. ClearSky – Fox Kitten – Widespread Iranian Espionage-Offensive Campaign (2020). (clearskysec.com)
  5. Kaspersky – A 6-year cyberespionage campaign… (Ferocious Kitten, 2021). (Kaspersky)

Hugging Face wykorzystany do dystrybucji tysięcy wariantów malware na Androida: kampania TrustBastion i „Premium Club”

Wprowadzenie do problemu / definicja luki

W końcówce stycznia 2026 r. badacze opisali kampanię Android RAT, w której przestępcy wykorzystali Hugging Face jako „zaufaną” infrastrukturę do hostowania i pobierania złośliwych plików APK. To nie jest klasyczna „luka” w sensie CVE, lecz nadużycie platformy (abuse): atakujący składowali payload w repozytoriach/datasetach, a ofiara pobierała go z domen i CDN, które rzadziej wzbudzają podejrzenia lub blokady.

W skrócie

  • Infekcja startowała od droppera „TrustBastion” podszywającego się pod narzędzie bezpieczeństwa i straszącego „zainfekowanym telefonem”.
  • Dropper nie serwował malware bezpośrednio – pobierał link przekierowujący do datasetu na Hugging Face, skąd ściągany był docelowy APK (również przez CDN Hugging Face).
  • Kampania używała polimorfizmu po stronie serwera: nowe warianty payloadu pojawiały się ~co 15 minut; repozytorium miało >6 tys. commitów w ~29 dni.
  • Payload nadużywał Accessibility Services oraz żądał uprawnień do overlay, przechwytywania ekranu itp., by kraść dane logowania (m.in. podszycia pod Alipay i WeChat) i utrzymać kontrolę.

Kontekst / historia / powiązania

To zdarzenie wpisuje się w szerszy trend: platformy współdzielenia artefaktów (repozytoria kodu, paczek, modeli, datasetów) są atrakcyjne dla atakujących, bo zapewniają:

  • renomę domeny (mniejsza podejrzaność),
  • wygodny hosting i dystrybucję,
  • szybkie iteracje (automatyzacja publikacji nowych wariantów).

W przypadku Hugging Face problem nie jest nowy: społeczność i firmy bezpieczeństwa od co najmniej 2024 r. ostrzegają przed możliwością dostarczania złośliwych treści (np. modeli prowadzących do wykonania kodu przy ładowaniu).
Jednocześnie Hugging Face rozwija mechanizmy bezpieczeństwa dla zasobów AI (np. skanowanie i alerty realizowane we współpracy z Protect AI), ale omawiana kampania pokazuje, że przestępcy potrafią „zmieścić się” w lukach kontroli treści – szczególnie gdy w grę wchodzą pliki binarne/instalatory i agresywny polimorfizm.

Analiza techniczna / szczegóły luki

1) Łańcuch infekcji (dropper → payload)

  1. Ofiara trafia na reklamę/scareware sugerującą infekcję i instalację „ochrony”. Instaluje aplikację TrustBastion (sideload).
  2. Po uruchomieniu dropper wyświetla obowiązkowy „update” z elementami łudząco podobnymi do Google Play/systemu.
  3. Dropper łączy się z trustbastion[.]com, ale zamiast pobierać APK, dostaje odpowiedź zawierającą URL do Hugging Face (dataset/repo), skąd pobiera finalny payload (APK) – finalnie po redirect do CDN Hugging Face.

2) Skala i polimorfizm

Bitdefender odnotował masowe tempo zmian: nowe buildy wrzucane ok. co 15 minut, a repozytorium miało ponad 6000 commitów przy wieku ok. 29 dni (w momencie analizy). Cel: omijanie detekcji opartej o hashe.

3) Zachowanie payloadu (RAT/spyware)

Po instalacji payload:

  • nakłania do włączenia Accessibility Services, podszywając prośbę pod „funkcję bezpieczeństwa/verification”; po uzyskaniu dostępu RAT zyskuje szeroką obserwowalność i kontrolę interakcji użytkownika,
  • dodatkowo prosi o uprawnienia umożliwiające nagrywanie/udostępnianie ekranu oraz overlay, co pozwala przechwytywać i manipulować treścią na ekranie w czasie rzeczywistym,
  • pokazuje fałszywe ekrany logowania (m.in. podszycia pod Alipay i WeChat) w celu kradzieży danych uwierzytelniających oraz przechwytuje informacje dot. blokady ekranu.

4) C2 i wskaźniki (IOCs) z publikacji badaczy

W raporcie wskazano m.in.:

  • C2: IP 154.198.48.57 (port 5000) i domenę trustbastion[.]com, a także w „drugiej fali” au-club[.]top oraz IP 108.187.7.133.
  • przykładowe nazwy pakietów: m.in. rgp.lergld.vhrthg oraz com.nrb.phayrucq.

Uwaga operacyjna: IoC szybko się „starzeją” w kampaniach polimorficznych. Traktuj je jako punkt startowy do polowań (threat hunting), nie jako jedyny warunek blokady.

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników: przejęcie kont finansowych/płatniczych (phishing overlay + przechwytywanie ekranu), utrata kontroli nad urządzeniem (nadużycia Accessibility), potencjalne blokowanie prób usunięcia.
  • Dla organizacji: ryzyko kompromitacji telefonów służbowych (BYOD/COPE), eskalacja do wycieku danych (np. kody jednorazowe, dane logowania, treści ekranów), a także trudniejsze blokowanie ze względu na „zaufany” kanał pobierania (Hugging Face/CDN).
  • Dla platform: presja na rozszerzanie skanowania treści (nie tylko typowe pliki ML), lepsze reagowanie na abuse i wykrywanie anomalii (np. tysiące commitów w krótkim czasie w datasetach z binariami).

Rekomendacje operacyjne / co zrobić teraz

Jeśli bronisz środowiska firmowego (SOC/IT/MDM)

  1. Zablokuj sideloading (instalacje spoza sklepów) politykami MDM – to kluczowy punkt wejścia w tej kampanii.
  2. Wymuś polityki dla Accessibility Services: blokada/whitelist, alerty na nowe usługi dostępności, korelacja z overlay/screen capture.
  3. Dodaj detekcje sieciowe:
    • połączenia do wskazanych domen/IP (z zastrzeżeniem rotacji infrastruktury),
    • nietypowe pobrania plików APK z endpointów typu huggingface.co/.../resolve/.../*.apk.
  4. Threat hunting na urządzeniach: szukaj nazw pakietów wskazanych w IoC i anomalii uprawnień (Accessibility + overlay + screen capture).

Jeśli jesteś użytkownikiem Androida

  • Instaluj aplikacje wyłącznie z oficjalnych sklepów, unikaj „antywirusów” z reklam straszących infekcją.
  • Gdy aplikacja prosi o Ułatwienia dostępu, overlay lub przechwytywanie ekranu „bo inaczej nie zadziała” — potraktuj to jako czerwony alarm.

Jeśli utrzymujesz repozytoria/artefakty (DevSecOps / platform security)

  • Monitoruj i automatycznie flaguj:
    • nietypowe typy plików (np. APK w datasetach),
    • wysoką dynamikę commitów,
    • repozytoria służące wyłącznie jako „magazyn binarek”.
  • Rozważ skanowanie wielowarstwowe (signatures + heurystyka + reputacja) oraz szybki proces takedown po zgłoszeniach — w tej kampanii zgłoszenie doprowadziło do usunięcia złośliwych datasetów.

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

  • Tu Hugging Face był użyty głównie jako hosting payloadu APK i kanał dystrybucji (zaufana domena + CDN) w kampanii mobilnej.
  • W innych incydentach związanych z Hugging Face ryzyko częściej dotyczyło złośliwych modeli/plików typu pickle i wykonania kodu po stronie środowisk ML (supply chain dla data science). To inna powierzchnia ataku, ale wspólny mianownik jest ten sam: nadużycie otwartego ekosystemu dystrybucji artefaktów.

Podsumowanie / kluczowe wnioski

  1. Kampania TrustBastion pokazuje, że atakujący potrafią skutecznie wykorzystywać zaufane platformy (tu: Hugging Face) jako etap dystrybucji malware.
  2. Polimorfizm co ~15 minut i tysiące commitów w krótkim czasie to sygnał, że obrona „po hashach” nie wystarcza – potrzebne są detekcje behawioralne i kontrola uprawnień.
  3. W Androidzie krytycznym wektorem jest Accessibility + overlay/screen capture: to duet, który umożliwia realne przejęcie sesji i kradzież danych finansowych.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i kontekst nadużycia Hugging Face (29 stycznia 2026). (BleepingComputer)
  2. Bitdefender Labs – analiza techniczna TrustBastion/Premium Club, polimorfizm, uprawnienia, C2, IoC (29 stycznia 2026). (Bitdefender)
  3. Hugging Face Docs – mechanizm Malware Scanning (ClamAV) dla repozytoriów. (Hugging Face)
  4. Hugging Face Blog – współpraca z Protect AI i skanowanie modeli/alerty bezpieczeństwa (kwiecień 2025). (Hugging Face)
  5. JFrog Security Research – kontekst złośliwych modeli na Hugging Face i ryzyk supply chain (luty 2024). (JFrog)

Viralowy Moltbot (ex Clawdbot) i ryzyka dla bezpieczeństwa danych: co naprawdę jest problemem i jak to opanować

Wprowadzenie do problemu / definicja luki

Moltbot (wcześniej znany jako Clawdbot) to open-source’owy „asystent AI z rękami”: działa lokalnie, ma pamięć długoterminową i potrafi integrować się z komunikatorami, e-mailem, systemem plików oraz wykonywać akcje (włącznie z komendami powłoki) w imieniu użytkownika. Taka „agentowość” zmienia model zagrożeń: to już nie tylko ryzyko halucynacji w odpowiedzi, ale realne ryzyko wycieku sekretów, przejęcia kont i wykonania poleceń – szczególnie gdy wdrożenie jest nieprawidłowo wystawione do Internetu.

Kluczowy problem, który wywołał falę ostrzeżeń, nie jest „magiczną luką zero-day”. To kombinacja zbyt szerokich uprawnień agenta + błędów konfiguracji (np. reverse proxy) + rozszerzalności przez skille, które razem potrafią dać atakującemu „panel sterowania” do Twojego środowiska.

W skrócie

  • Badacze wskazują na setki publicznie dostępnych paneli administracyjnych/„control” wynikających z konfiguracji reverse proxy, gdzie ruch z Internetu bywa traktowany jako „lokalny” i automatycznie zaufany.
  • W konsekwencji możliwe są: podgląd historii rozmów, kradzież kluczy API/OAuth, kradzież danych konfiguracyjnych, a w skrajnych przypadkach nawet wykonywanie poleceń na hoście (czasem z podwyższonymi uprawnieniami).
  • Architektura agentowa (gateway + kanały + narzędzia + skille) zwiększa powierzchnię ataku, a prompt injection i „zatrute” skille są realnym wektorem nadużyć.
  • Da się to zabezpieczyć, ale wymaga podejścia „default deny”: sandbox, allow-listy, separacja tożsamości/tokonów oraz audyt i logowanie działań agenta.

Kontekst / historia / powiązania

Według opisu w branżowych publikacjach Moltbot bardzo szybko „złapał” viral – bo obiecuje to, co dla wielu jest naturalnym kolejnym krokiem: osobistego agenta 24/7, który nie tylko odpowiada, ale robi rzeczy (przypomina, uruchamia zadania, integruje aplikacje).

I tu pojawia się klasyczny paradoks „lokalnie = bezpiecznie”: samo hostowanie u siebie nie rozwiązuje problemu, jeśli:

  • wystawisz interfejs administracyjny do Internetu,
  • agent przechowuje sekrety lokalnie,
  • a jego „umiejętności” (skille) instalujesz jak wtyczki z Internetu.

Analiza techniczna / szczegóły luki

1) Ekspozycja paneli administracyjnych przez reverse proxy i „zaufanie do localhost”

Najczęściej opisywany scenariusz to sytuacja, w której instancja Moltbot/Clawdbot stoi za reverse proxy, a logika „auto-approve dla lokalnych połączeń” zostaje przypadkowo przeniesiona na cały ruch przychodzący. Skutek: interfejs administracyjny może działać jak „otwarte drzwi” bez uwierzytelnienia.

2) Co można wyciągnąć z przejętej lub źle wystawionej instancji

W opisach incydentów przewijają się szczególnie:

  • klucze API i tokeny OAuth,
  • historia rozmów (często zawiera wrażliwe dane i „kontekst operacyjny”),
  • potencjalnie dane konfiguracyjne integracji z komunikatorami i narzędziami,
  • a w cięższych przypadkach: wykonywanie poleceń na hoście, zależnie od tego, jakie uprawnienia dostał agent.

3) Skille jako wektor łańcucha dostaw (supply chain)

Moltbot jest rozszerzalny przez skille. To super funkcja… i super problem. BleepingComputer opisuje demonstrację, w której skill został opublikowany w oficjalnym rejestrze, „wypromowany” sztucznie i szybko pobrany przez użytkowników – pokazując, jak łatwo jest wciągnąć kogoś w instalację niezweryfikowanego modułu.

Cisco idzie krok dalej i pokazuje, że skill może zawierać instrukcje prowadzące do cichej eksfiltracji danych (np. poprzez polecenia sieciowe), a także mechanizmy przypominające prompt injection, które próbują ominąć bezpieczne zachowanie agenta.

4) Prompt injection w agentach: „słabość systemowa”, nie pojedynczy błąd

Snyk zwraca uwagę, że prompt injection to fundamentalna klasa ryzyk dla agentów czytających dane z zewnątrz (poczta, web, komunikatory). Jeśli agent ma dostęp do narzędzi (shell, pliki, sieć), „złośliwy prompt” może stać się poleceniem operacyjnym.

Praktyczne konsekwencje / ryzyko

Dla organizacji ryzyko nie kończy się na „ktoś zobaczy czat”. Jeśli pracownik podłączy agenta do narzędzi firmowych, realne stają się scenariusze:

  • wyciek sekretów (API keys, tokeny), które potem umożliwiają dostęp do repozytoriów, CI/CD, chmury, ticketingu,
  • przejęcie tożsamości w komunikatorach (bot wysyłający wiadomości „w Twoim imieniu”),
  • lateral movement przez integracje (agent jako nowy „principal” w systemie),
  • wykonanie poleceń na hoście w zależności od konfiguracji i trybu uprawnień.

Co ważne, BleepingComputer przytacza tezę firmy Token Security, że z narzędzia korzystają też pracownicy w środowiskach enterprise – potencjalnie poza kontrolą IT (shadow IT), co utrudnia zarządzanie ryzykiem.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które można wdrożyć od razu (w duchu „minimum konieczne”, zanim agent dostanie jakiekolwiek realne uprawnienia):

1) Nie wystawiaj panelu/gateway’a do Internetu

  • Zwiąż nasłuch do loopback/localhost i nie polegaj na „zaufaniu do lokalnych połączeń”, jeśli stoi przed tym reverse proxy.
  • Jeśli musisz mieć dostęp zdalny: użyj VPN/Zero Trust, silnego uwierzytelnienia i restrykcji źródeł (allowFrom/ACL).

2) Sandbox jako domyślny tryb pracy

Uruchamiaj agenta w VM/kontenerze/devboxie, z dostępem tylko do jednego katalogu projektu, nie do całego home, a już na pewno nie do ~/.ssh czy globalnych konfiguracji.

3) Allow-listy: komendy, ścieżki, integracje, sieć

  • Biała lista komend i katalogów (read/write),
  • biała lista integracji (tylko to, co niezbędne),
  • potwierdzanie operacji wysokiego ryzyka (instalacje, zmiany uprawnień, operacje destrukcyjne).

4) Higiena sekretów i „osobne tożsamości” dla agenta

  • Tokeny zakresowe i krótkotrwałe zamiast pełnych i długowiecznych,
  • osobny zestaw poświadczeń dla agenta (najlepiej tylko do niezbędnych zasobów),
  • załóż, że wszystko co agent „widzi” może kiedyś wyciec (logi, pamięć, artefakty narzędzi).

5) Skille traktuj jak zależności w supply chain

  • Instaluj tylko zaufane skille, najlepiej wewnętrznie zatwierdzone,
  • rozważ skanowanie i przegląd treści skilli (Cisco opisuje podejście „skill scanner” i typowe znaleziska).

6) Audyt i logowanie działań agenta

  • Logi wykonywanych narzędzi/komend i dostępu do plików,
  • szybki „kill switch” na integracje,
  • okresowy przegląd uprawnień i reset do minimum.

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

Moltbot vs klasyczne chatboty SaaS:
W typowym czacie w chmurze największym ryzykiem jest ujawnienie danych w rozmowie albo błędna odpowiedź. W agentach lokalnych ryzyko przenosi się na warstwę operacyjną: agent ma narzędzia (shell, pliki, integracje) i może wykonać akcję, której skutków nie da się „odkręcić” jednym kliknięciem.

Moltbot vs klasyczne wtyczki/IDE extensions:
Tu wchodzimy w podobny model zagrożeń jak przy rozszerzeniach: instalujesz cudzy kod/instrukcje, które działają w Twoim kontekście. Różnica polega na tym, że agent może dodatkowo „interpretować” wejście (prompt injection) i łączyć dane z wielu kanałów, co zwiększa szanse na nadużycie.

Podsumowanie / kluczowe wnioski

Moltbot/Clawdbot nie jest „z definicji zły” – ale jest przykładem narzędzia, które radykalnie podnosi stawkę: tożsamość + integracje + narzędzia + pamięć tworzą nowy, bardzo uprzywilejowany „byt” w systemie. Największe problemy, które teraz wypływają, wynikają z:

  • błędów wdrożeniowych (reverse proxy i ekspozycja paneli),
  • braku izolacji (sandbox),
  • oraz braku twardych ograniczeń (allow-listy, kontrola skilli, higiena sekretów).

Jeśli potraktujesz agenta jak „juniora z rootem” (a nie „zabawkę do czatu”), możesz korzystać z niego bez zamieniania produktywności w incydent.

Źródła / bibliografia

  1. BleepingComputer — „Viral Moltbot AI assistant raises concerns over data security” (28 stycznia 2026). (BleepingComputer)
  2. Snyk — „Your Clawdbot AI Assistant Has Shell Access and One Prompt Injection Away from Disaster”. (Snyk)
  3. Bitdefender Hotforsecurity — „Moltbot security alert… exposed control panels risk credential leaks and account takeovers” (27 stycznia 2026). (Bitdefender)
  4. Cisco Blogs — „Personal AI Agents like Moltbot Are a Security Nightmare”. (Cisco Blogs)
  5. Auth0 Blog — „Securing Moltbot: A Developer’s Checklist for AI Agent Security” (28 stycznia 2026). (Auth0)

Operacja „Bizarre Bazaar”: jak cyberprzestępcy przejmują wystawione endpointy LLM i monetyzują dostęp do AI

Wprowadzenie do problemu / definicja luki

„LLMjacking” to nadużycie infrastruktury dużych modeli językowych (LLM) przez osoby nieuprawnione — analogicznie do cryptojackingu, ale zamiast kopania kryptowalut na cudzym CPU/GPU, celem jest wykonywanie kosztownej inferencji, kradzież danych z kontekstu rozmów, a nawet próby wejścia głębiej w sieć przez integracje typu MCP.

W styczniu 2026 nagłośniono kampanię nazwaną Operation Bizarre Bazaar, w której atakujący polują na wystawione do internetu lub słabo uwierzytelnione endpointy LLM (np. self-hosted) i budują wokół tego cały „łańcuch dostaw” — od skanowania, przez walidację, po odsprzedaż dostępu w formie quasi-komercyjnej usługi.

W skrócie

  • Badacze Pillar Security zarejestrowali ~35 000 sesji ataków na honeypotach w oknie ok. 40 dni (grudzień 2025 – styczeń 2026).
  • Najczęściej wykorzystywane „wejścia” to domyślne/odsłonięte porty i brak kontroli dostępu, m.in. Ollama na 11434 oraz OpenAI-compatible API na 8000.
  • Model działania obejmuje: Scanner → Validator → Marketplace, gdzie rynek miał funkcjonować pod domeną silver[.]inc, promując „unified gateway” do wielu modeli.
  • Poza kradzieżą zasobów i odsprzedażą API, ryzyko dotyczy wycieku danych z promptów/konwersacji oraz pivotu przez serwery MCP (łączenie LLM z plikami, DB, API).

Kontekst / historia / powiązania

Zainteresowanie atakujących powierzchnią AI rośnie, bo:

  1. inferencja bywa droga (szczególnie przy GPU),
  2. endpointy LLM często są wdrażane „startupowo” — szybko, w środowiskach dev/stage, z publicznym IP,
  3. integracje narzędziowe (np. MCP) łączą LLM z zasobami o realnej wartości.

Niezależnie od Bizarre Bazaar, GreyNoise opisało w styczniu 2026 metodyczne mapowanie i sondowanie dziesiątek endpointów modeli oraz szukanie błędnych konfiguracji mogących ujawniać dostęp do komercyjnych API.

Analiza techniczna / szczegóły luki

1) Jak wybierane są cele

Według Pillar Security, przestępcy korzystają z narzędzi typu Shodan/Censys i reagują szybko — próby nadużyć pojawiają się w ciągu godzin od tego, gdy źle skonfigurowany endpoint zacznie być widoczny w wynikach skanów.

Typowe „higieniczne” błędy:

  • brak uwierzytelniania i autoryzacji,
  • wystawienie dev/stage na publiczny adres,
  • brak limitów (rate limiting / quota),
  • brak segmentacji sieciowej i egress control,
  • publicznie dostępne integracje MCP.

2) Najczęstsze wektory wejścia (konkretne przykłady)

Wskazane w raportach przykłady misconfigów:

  • Ollama bez auth na porcie 11434,
  • OpenAI-compatible endpoints na 8000 dostępne z internetu,
  • wystawione serwery MCP bez kontroli dostępu.

3) Łańcuch dostaw cyberprzestępców: Scanner → Validator → Marketplace

Pillar opisuje trójfazowy model:

  • Scanner: rozproszona infrastruktura botów kataloguje odsłonięte endpointy LLM/MCP,
  • Validator: waliduje działanie API (testy, enumeracja możliwości/modeli),
  • Marketplace: monetyzuje dostęp — w raporcie wskazano silver[.]inc jako „bramę” odsprzedającą dostęp do wielu dostawców i promującą projekt „NeXeonAI”.

4) Oddzielna aktywność wokół MCP

W raporcie Pillar pojawia się też wątek osobnej kampanii rozpoznawczej ukierunkowanej na endpointy MCP, gdzie stawką bywa nie tylko koszt inferencji, ale potencjalny dostęp do zasobów (np. interakcje z Kubernetes, dostęp do usług chmurowych, wykonanie poleceń) — co w praktyce może być bardziej wartościowe niż samo „podkradanie” tokenów.

Praktyczne konsekwencje / ryzyko

  1. Koszty i nadużycia zasobów
    Nieautoryzowane użycie inferencji może wygenerować duże rachunki lub zajechać GPU/CPU (DoS kosztowy). Pillar opisuje odsprzedaż dostępu z „rabatem” w modelu przestępczym.
  2. Wyciek danych z promptów i historii konwersacji
    Jeśli endpoint umożliwia wgląd w kontekst, logi, historię rozmów lub jeśli aplikacja nie izoluje tenantów/sesji, atakujący może wyciągnąć dane wrażliwe (PII, fragmenty kodu, treści biznesowe).
  3. Pivot do sieci wewnętrznej przez integracje (MCP / narzędzia)
    Jeżeli MCP/agent ma uprawnienia do plików, baz danych czy wewnętrznych API, „tylko” odsłonięty endpoint AI staje się punktem wejścia do klasycznych ataków na środowisko.
  4. Ryzyko reputacyjne i prawne
    Wycieki danych klientów, utrata poufności, potencjalne naruszenia RODO/umów, a do tego przerwy w działaniu usług (chatboty, support, sprzedaż).

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu” (praktyka z SOC/CloudSec):

1) Odcięcie ekspozycji i twarde uwierzytelnienie

  • Nie wystawiaj endpointów LLM/MCP bezpośrednio do internetu; schowaj je za VPN/ZTNA lub reverse proxy.
  • Wymuś mTLS / OAuth2 / signed JWT / silne API keys + rotacja sekretów.
  • Zastosuj IP allowlist (tam, gdzie to realne).

2) Kontrole kosztowe i anty-abuse

  • Rate limiting / quotas per client, limity tokenów, limity równoległości.
  • Alerty na anomalia: skoki requestów, nietypowe modele, nietypowe godziny, długie konteksty.

3) Telemetria i detekcja

  • Loguj: źródłowe IP, user agent, klucze, endpointy, liczbę tokenów, czasy odpowiedzi, błędy 401/403.
  • Koreluj z widocznością w Shodan/Censys (monitoring zewnętrzny własnych adresów).

4) Twarde zasady dla MCP / agentów i integracji narzędziowych

  • Least privilege dla narzędzi (filesystem/DB/API), osobne konta serwisowe, minimalne scope.
  • Rozdziel sieciowo warstwę LLM od zasobów krytycznych (segmentacja).
  • Wprowadź polityki „tool allowlist” i ograniczenia komend/operacji (szczególnie tam, gdzie możliwe jest wykonywanie poleceń).

5) Higiena wdrożeń self-hosted (Ollama/vLLM i podobne)

  • Zmień domyślne ustawienia, wyłącz publiczne bindy, nie zostawiaj portów typu 11434/8000 na WAN.
  • Traktuj dev/stage jak produkcję: brak publicznych IP, brak „tymczasowo otwartego” API.

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

  • Cryptojacking vs LLMjacking: w obu przypadkach kradniesz moc obliczeniową, ale przy LLM dochodzi wyższa wrażliwość danych (kontekst rozmów) i częściej ścieżka do systemów wewnętrznych przez integracje (MCP/agent tools).
  • Skanowanie/rekonesans vs monetyzacja: GreyNoise opisywało kampanie silnie rekonesansowe, budujące listy celów i testujące formaty API. Z kolei Bizarre Bazaar (wg Pillar) idzie krok dalej — domyka pętlę „biznesową” przez walidację i odsprzedaż dostępu.

Podsumowanie / kluczowe wnioski

  • Wystawione endpointy LLM/MCP przestały być „niszowym problemem” — pojawił się powtarzalny model przestępczy z monetyzacją.
  • Największe ryzyko to nie tylko rachunki za GPU, ale też wyciek danych i pivot do wnętrza organizacji przez integracje narzędziowe.
  • Najskuteczniejsza obrona jest nudna, ale działa: brak ekspozycji do internetu + silne auth + limity + monitoring + least privilege dla MCP.

Źródła / bibliografia

  1. Pillar Security — Operation Bizarre Bazaar: First Attributed LLMjacking Campaign… (28 stycznia 2026). (pillar.security)
  2. BleepingComputer — Hackers hijack exposed LLM endpoints in Bizarre Bazaar operation (28 stycznia 2026). (BleepingComputer)
  3. CSO Online — Crooks are hijacking and reselling AI infrastructure: Report (28 stycznia 2026). (CSO Online)
  4. GreyNoise — Threat Actors Actively Targeting LLMs (8 stycznia 2026). (greynoise.io)
  5. SecurityWeek — LLMs in Attacker Crosshairs, Warns Threat Intel Firm (12 stycznia 2026). (SecurityWeek)

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 siec