Archiwa: LLM - Strona 8 z 11 - Security Bez Tabu

Tag: LLM

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)

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 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)

KONNI wykorzystuje AI do budowy backdoora w PowerShell i celuje w deweloperów (blockchain/crypto)

Wprowadzenie do problemu / definicja luki

W styczniu 2026 Check Point Research opisał aktywną kampanię phishingową przypisywaną do KONNI – północnokoreańskiego aktora działającego co najmniej od 2014 roku. Tym razem kluczową zmianą jest dobór ofiar (software development/engineering) oraz narzędzie egzekucji: backdoor w PowerShell, którego cechy wskazują na AI-assist/AI-generated development (nie tyle nowe TTP, co szybsze i „czyściejsze” wytwarzanie kodu z typowymi artefaktami LLM).

W praktyce nie jest to „pojedyncza luka CVE”, ale łańcuch infekcji oparty o socjotechnikę, pliki skrótów Windows (LNK) i wieloetapowe uruchomienie komponentów, którego efektem jest trwały dostęp do hosta oraz możliwość dalszej eskalacji do narzędzi zdalnego zarządzania.

W skrócie

  • Kampania celuje w deweloperów i zespoły inżynieryjne z dostępem do zasobów blockchain/crypto (repozytoria, API, portfele, infrastruktura).
  • Start łańcucha: link hostowany na Discord → pobranie ZIP z przynętą (PDF) i LNK, który uruchamia loader PowerShell i rozpakowuje kolejne elementy (DOCX + CAB).
  • Utrwalenie: Scheduled Task podszywający się pod OneDrive, uruchamiany cyklicznie, deszyfrujący (XOR) i wykonujący backdoor „in-memory”.
  • Backdoor zawiera rozbudowane anti-analysis (progi sprzętowe, blacklist narzędzi, wymaganie aktywności myszą), fingerprinting przez WMI oraz mechanizmy eskalacji UAC (fodhelper).
  • C2: obejście „bramki” po stronie serwera przez emulację JavaScript challenge i pozyskanie cookie __test, a potem cykliczne wysyłanie metadanych hosta do endpointu PHP.

Kontekst / historia / powiązania

KONNI historycznie kojarzono głównie z celami w Korei Południowej (dyplomacja, rząd, NGO, akademia) oraz klasycznym spear-phishingiem opartym o tematy geopolityczne. W opisywanej kampanii widać przesunięcie na ekosystemy techniczne: development i obszary, gdzie pojedynczy kompromitowany endpoint może otworzyć drogę do kontenerów, CI/CD, sekretów w repozytoriach czy kluczy do usług.

Z szerszej perspektywy to pasuje do obserwacji, że północnokoreański program cyber jest wykorzystywany nie tylko do szpiegostwa, ale również do operacji generujących środki finansowe, m.in. przez kradzieże kryptowalut i naruszenia sankcji.

Analiza techniczna / szczegóły luki

1) Przynęty i initial access

Przynęty wyglądają jak materiały projektowe (architektura, stack, harmonogramy, budżety/milestones) powiązane z blockchain/crypto. Wektor początkowy wprost nie jest ujawniony, ale łańcuch startuje od linku hostowanego na Discord, prowadzącego do archiwum ZIP.

Z perspektywy MITRE ATT&CK to klasyczny przypadek User Execution: Malicious File (T1204.002) – ofiara musi otworzyć/uruchomić spreparowany plik (tu: LNK).

2) Łańcuch infekcji (ZIP → LNK → CAB → BAT/PS1)

W ZIP znajdują się PDF (lure) oraz LNK. LNK uruchamia osadzony loader PowerShell, który:

  • zapisuje na dysk przynętę DOCX i archiwum CAB (oba osadzone w LNK i XOR-owane jednobajtowym kluczem),
  • otwiera DOCX, żeby odciągnąć uwagę,
  • rozpakowuje CAB, gdzie znajdują się: PowerShell backdoor, dwa batch file oraz exe do UAC bypass,
  • uruchamia pierwszy batch.

3) Persistence i „living off the land”

Pierwszy batch tworzy staging w C:\ProgramData, przenosi komponenty i zakłada Scheduled Task podszywający się pod zadanie OneDrive uruchamiane co godzinę. Zadanie czyta zaszyfrowany backdoor, wykonuje XOR-decrypt (klucz ‘Q’) i uruchamia kod w pamięci. Następnie batch usuwa się z dysku (redukcja śladów).

4) Cechy sugerujące AI-generated backdoor

CPR wskazuje na nietypowo „produktowy” charakter skryptu: czytelna struktura, komentarze/dokumentacja oraz artefakt wprost przypominający placeholder z generatorów LLM: komentarz w rodzaju „your permanent project UUID” (instrukcja dla człowieka jak uzupełnić wartość). To zestaw sygnałów, który ma wspierać tezę o AI-assist/AI-generated development.

5) Funkcje backdoora: anti-analysis, identyfikacja hosta, eskalacja

Backdoor wykonuje:

  • anti-analysis/sandbox evasion: progi sprzętowe, wykrywanie narzędzi (IDA, Wireshark, Procmon itd.), wymaganie interakcji użytkownika (ruch/kliknięcia myszy),
  • single-instance przez mutex Global\SysInfoProject_<projectUUID> (UUID stały dla próbek wskazanych w raporcie),
  • fingerprinting przez WMI (m.in. serial płyty głównej + UUID systemu), SHA-256 i skrócenie do 16 znaków,
  • rozgałęzienie działań wg uprawnień: dla „User” – fodhelper UAC bypass przez manipulacje w HKCU\Software\Classes i przekierowanie protokołu ms-settings, a następnie modyfikację ConsentPromptBehaviorAdmin (de facto ograniczenie promptów UAC dla adminów).

Dodatkowo, w scenariuszu „Admin” raport opisuje m.in. dodanie wykluczenia Windows Defender dla C:\ProgramData i podmianę zadania harmonogramu na wersję z wyższym kontekstem uprawnień.

6) C2 i obejście „bramki” anty-bot

C2 jest zabezpieczone client-side’ową „bramką” (AES/JS) i cookie __test. Backdoor emuluje JavaScript challenge: pobiera implementację AES używaną przez stronę, odtwarza logikę JS, odszyfrowuje ciphertext z serwera i wyciąga token, a następnie używa go jako cookie do kolejnych żądań. Potem okresowo wysyła metadane hosta (ID, poziom uprawnień, IPv4, username) do endpointu PHP, a odpowiedzi traktuje jako tasking (PowerShell wykonywany w tle).

7) Warianty i IoC

CPR wspomina też o wariancie z października 2025, gdzie początkowy payload był wprost obfuskowanym skryptem PowerShell pobierającym kolejne komponenty, a OneDriveUpdater.exe służył głównie do pobrania i uruchomienia klienta SimpleHelp (legit RMM) dla interaktywnego dostępu.

W raporcie podano też przykładowe domeny/IP C2 oraz listy hashy (IoC).

Praktyczne konsekwencje / ryzyko

Dla organizacji software’owych i zespołów blockchain/crypto ryzyko jest szczególne, bo kompromitacja jednego stanowiska developerskiego może przełożyć się na:

  • wyciek sekretów z repozytoriów (tokeny do Git, klucze API, SSH),
  • przejęcie CI/CD (wstrzyknięcia w pipeline, supply-chain),
  • dostęp do środowisk chmurowych i walletów/kluczy podpisujących,
  • lateral movement do zasobów produkcyjnych.

Kontekst finansowy jest istotny: w oficjalnych opracowaniach dot. aktywności DPRK podkreśla się skalę cyber-kradzieży i ich rolę w finansowaniu działań państwa, w tym obchodzeniu sankcji.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  1. Zablokuj/ogranicz uruchamianie LNK z pobranych archiwów i katalogów typu Downloads/Temp (tam, gdzie to możliwe politykami). To bezpośrednio tnie klasę ataków „malicious file + user execution”.
  2. Polowanie na Scheduled Tasks podszywające się pod OneDrive i uruchamiające inline PowerShell (szczególnie z odczytem bajtów z C:\ProgramData\… i natychmiastowym IEX).
  3. Telemetria EDR: alerty na PowerShell obfuskowany arytmetyką, nietypowe tworzenie słowników stringów + Invoke-Expression.
  4. Wykrywanie zmian w rejestrze pod fodhelper UAC bypass (ścieżki pod HKCU\Software\Classes i ms-settings) oraz modyfikacji ConsentPromptBehaviorAdmin.
  5. Network: blokady/alerty na wskazane w raporcie domeny/IP oraz na nietypowe żądania do endpointów PHP po wcześniejszym „handshake” z cookie __test.

Średni termin (1–4 tygodnie)

  • Hardening stacji dev: separacja kont, MFA wszędzie, minimalizacja lokalnych uprawnień admin, izolacja sekretów (vault), rotacja tokenów.
  • Ograniczenie możliwości dodawania Defender exclusions i monitorowanie wykluczeń dla C:\ProgramData.
  • Kontrole supply-chain: podpisywanie artefaktów, wymuszenie code review dla zmian w pipeline, zasada „two-person rule” dla kluczy produkcyjnych.
  • Uświadamianie: „projektowe PDF/DOCX z Discorda” jako realna przynęta dla devów – to dziś równie typowe jak „faktura” w klasycznych kampaniach.

Różnice / porównania z innymi przypadkami

  • KONNI (AI-assist backdoor): raportowane elementy wskazują na wykorzystanie AI głównie do wytwarzania/formatowania kodu (komentarze-artefakty, modularność), przy zachowaniu znanych TTP (LNK, scheduled task, PowerShell).
  • Szerszy trend AI-generated malware: Check Point kilka dni wcześniej opisał „VoidLink” jako przykład bardziej „frameworkowego” podejścia, gdzie AI miało przyspieszać nie tylko pisanie kodu, ale też planowanie i iterację całego projektu. To sugeruje, że „AI w malware” szybko przesuwa się od ciekawostek do realnego przyspieszacza R&D po stronie atakujących.
  • LNK jako stały motyw: niezależnie od tej konkretnej kampanii, analizy TTP w regionie (w tym porównania aktorów państwowych) pokazują, że pliki LNK w archiwach ZIP są dojrzałym i powtarzalnym wzorcem initial access.

Podsumowanie / kluczowe wnioski

  1. KONNI rozszerza profil ofiar: deweloperzy + blockchain/crypto to atrakcyjny cel, bo daje dostęp do sekretów i infrastruktury o wysokiej wartości.
  2. Największa nowość nie leży w „magicznych” nowych technikach, tylko w tym, że AI może obniżać koszt i czas tworzenia użytecznych implantów (bardziej uporządkowany kod, szybkie wariantowanie).
  3. Obrona powinna iść dwutorowo: (a) twarde kontrole uruchamiania plików i PowerShell, (b) security hygiene w środowisku dev (sekrety, pipeline, uprawnienia).
  4. Warto traktować kanały typu Discord jako realny wektor dystrybucji „materiałów projektowych” – szczególnie w społecznościach dev/web3.

Źródła / bibliografia

  1. Check Point Research – KONNI Adopts AI to Generate PowerShell Backdoors (22 stycznia 2026). (Check Point Research)
  2. MITRE ATT&CK – User Execution: Malicious File (T1204.002). (attack.mitre.org)
  3. Genians – analiza spear-phishing i nadużyć LNK/ZIP w kampaniach APT (kontekst TTP). (genians.co.kr)
  4. MOFA Japan (PDF) – raport dot. naruszeń/obchodzenia sankcji i roli DPRK cyber (kontekst finansowy).
  5. Check Point – VoidLink Signals the Start of a New Era in AI-Generated Malware (19 stycznia 2026). (Check Point Blog)

VoidLink: cloud-native framework malware dla Linuksa, który (prawdopodobnie) powstał „prawie w całości” z pomocą AI

Wprowadzenie do problemu / definicja zagrożenia

VoidLink to zaawansowany, „cloud-first” framework malware dla Linuksa zaprojektowany pod długotrwały, dyskretny dostęp do środowisk chmurowych i kontenerowych (Kubernetes/Docker). Z perspektywy obrońców najważniejsze jest to, że nie wygląda jak typowy „jednofunkcyjny trojan” – bardziej przypomina kompletne C2/post-exploitation narzędzie z loaderami, implantami, mechanizmami rootkit oraz rozbudowanym systemem wtyczek.

W styczniu 2026 temat zyskał dodatkowy ciężar: Check Point Research wskazuje na rzadko spotykane dowody sugerujące, że znacząca część rozwoju VoidLink mogła zostać wykonana w trybie „AI-driven development” (agent + specyfikacje + sprinty), co radykalnie skraca czas tworzenia złożonych narzędzi ofensywnych.

W skrócie

  • Cel i środowisko: Linux w chmurze i kontenerach; rozpoznawanie dostawcy chmury oraz kontekstu (K8s/Docker) i dopasowanie zachowania.
  • Architektura: loader 2-etapowy + implant + in-memory plugin system (ponad 30 modułów; panel wskazywał ok. 37 wtyczek).
  • Stealth i rootkity: LD_PRELOAD / LKM / eBPF – wybór techniki zależny od wersji kernela i „postury” środowiska.
  • C2/łączność: wiele kanałów (m.in. HTTP/HTTPS, DNS, ICMP) oraz mechanizmy kamuflażu ruchu; w próbkach widać też kierunek „mesh/P2P”.
  • AI w wytwarzaniu: Check Point opisuje metodykę SDD (Spec Driven Development) i artefakty po narzędziu TRAE SOLO; THN i Sysdig przytaczają dodatkowe sygnały „LLM-owego” boilerplate’u.
  • Status: brak potwierdzonych infekcji „w realu” w momencie publikacji analiz; wygląda na projekt w fazie intensywnego rozwoju.

Kontekst / historia / powiązania

  • Wykrycie: Check Point Research trafił na próbki w grudniu 2025; część binariów zawierała artefakty developerskie (np. symbole debug), co sugerowało buildy „w trakcie” a nie masowo wdrożone malware.
  • Atrybucja (ostrożnie): w raportach pojawia się wątek środowiska developerskiego powiązanego językowo/operacyjnie z Chinami, ale bez twardego przypisania do konkretnej grupy.
  • Tempo rozwoju: Check Point wskazuje, że narzędzie urosło do ~88 tys. linii kodu do początku grudnia 2025; THN podkreśla „pierwszy funkcjonalny implant” w czasie krótszym niż tydzień.
  • „Wgląd w warsztat”: kluczowe w tej historii jest to, że badacze mieli wyjątkowy wgląd w artefakty planowania i budowy (m.in. przez błędy OPSEC autora i wyciek plików).

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy „tradecraftu” VoidLink, z perspektywy obrony chmury i Linuksa.

1) Cloud-first rozpoznanie i działania w kontenerach

VoidLink potrafi identyfikować popularnych dostawców chmury (m.in. AWS, Azure, GCP, Alibaba, Tencent) i pobierać dane z mechanizmów metadata/instancji. Dodatkowo wykrywa, czy działa w Dockerze lub w podzie Kubernetes, a następnie dobiera moduły post-exploitation (np. pod kątem eksfiltracji sekretów, prób „container escape”, ruchu lateralnego).

2) Modularność: Plugin API inspirowane Cobalt Strike

Check Point opisuje architekturę z własnym Plugin API inspirowanym podejściem Beacon Object Files (BOF). Wtyczki są ładowane w runtime i wykonywane in-memory, co sprzyja „cichym” operacjom i ogranicza artefakty na dysku. Kategorie modułów obejmują m.in. recon, cloud/container, credential harvesting, persistence, anti-forensics, lateral movement.

3) Rootkity i ukrywanie: LD_PRELOAD, LKM oraz eBPF

VoidLink ma „rootkit-style capabilities” w kilku wariantach:

  • LD_PRELOAD (user-mode hooking),
  • LKM (kernel module),
  • eBPF (hooking ścieżek w sposób lepiej dopasowany do nowszych, „utwardzonych” systemów).

Mechanizm doboru techniki zależy od kernela i dostępnych funkcji; celem jest m.in. ukrywanie procesów, plików i socketów, a także maskowanie samych komponentów.

4) C2 i kamuflaż ruchu

VoidLink obsługuje wiele transportów (HTTP/1.1, HTTP/2, WebSocket, DNS, ICMP) oraz warstwy kamuflażu (udawanie „legitnego” ruchu, pakowanie danych w obiekty przypominające treści webowe/grafiki itp.). W kodzie widać też kierunek rozwoju w stronę mesh/P2P.

5) Adaptive stealth i OPSEC: „ryzyko” środowiska wpływa na zachowanie

Jedna z mocniejszych cech: po starcie malware ma enumerować zabezpieczenia (np. EDR/hardening), wyliczać risk score i na tej podstawie modyfikować agresywność działań (np. wolniejsze skanowanie w środowisku monitorowanym). Do tego dochodzą: runtime code encryption, mechanizmy anty-debug, integralność runtime oraz self-deletion przy wykryciu manipulacji.

6) „Server-Side Rootkit Compilation” (Sysdig)

Sysdig zwraca uwagę na element, który rozwiązuje klasyczny problem LKM rootkitów: portowalność względem wersji kernela. Według analizy, serwer C2 ma budować moduły kernela „na żądanie” pod konkretną wersję kernela ofiary (SRC). To może znacząco podnieść skuteczność w heterogenicznych flotach linuksowych w chmurze.

Praktyczne konsekwencje / ryzyko

Dla większości organizacji ryzyko nie sprowadza się do „jeszcze jednego malware”, tylko do możliwego przejęcia warstwy sterującej chmurą:

  • Kradzież poświadczeń i sekretów (cloud creds, tokeny, klucze, dane do repozytoriów/SCM typu Git) → ryzyko kompromitacji CI/CD, „secrets sprawl” i dostępu do kodu.
  • Trwała obecność w klastrach i node’ach dzięki persistence + ukrywaniu (rootkit/eBPF/LKM) oraz adaptacji do monitoringu.
  • Cichy post-exploitation w K8s/Docker (recon, eskalacje, potencjalne ucieczki z kontenera) → dostęp do workloadów i danych.
  • Zmiana ekonomii ataku dzięki AI: jeśli Check Point ma rację, bariera wejścia dla budowy „pełnego frameworka” spada – pojedynczy actor może iterować szybciej, niż zespoły defensywne aktualizują detekcje i polityki.

Jednocześnie warto trzymać w głowie fakt, że w analizach na styczeń 2026 nie ma potwierdzonych, masowych infekcji w środowiskach produkcyjnych – ale projekt wygląda jak „prawie gotowy” ekosystem C2.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają sens nawet wtedy, gdy VoidLink nie jest (jeszcze) „w wild”.

1) Detekcja runtime dla Linuksa i kontenerów

  • Postaw na runtime monitoring (syscall/activity-based), bo część technik jest „fileless” lub ukrywa artefakty na dysku. Sysdig podkreśla, że mimo zaawansowania zachowania na poziomie syscalls są widoczne dla narzędzi klasy runtime (np. Falco).
  • W K8s: reguły na nietypowe exec w kontenerach, dostęp do socketów dockera, nietypowe mounty, operacje na /proc, manipulacje BPF, ładowanie modułów kernela.

2) Ograniczenie „blast radius” w chmurze

  • Przejrzyj IAM: minimalne uprawnienia, krótkie TTL tokenów, rotacja kluczy, rozdzielenie ról CI/CD i adminów.
  • Uszczelnij dostęp do instance metadata (IMDS/metadata proxy), bo VoidLink aktywnie pyta o dane środowiska chmurowego.
  • Zredukuj ekspozycję sekretów: używaj menedżerów sekretów (i audytuj, gdzie lądują w env/args).

3) Twarde kontrole na hoście

  • Rozważ ograniczenia dla eBPF i ładowania modułów (tam, gdzie to możliwe operacyjnie).
  • Hardening: kontrola integralności, ograniczenie narzędzi developerskich na serwerach produkcyjnych, monitoring zmian w usługach/systemd/cron (persistence).

4) Kontrola egress i anomalii C2

  • Monitoruj/ogranicz: DNS tunneling, nietypowe ICMP, WebSocket/HTTP2 do nieznanych destynacji. VoidLink ma wiele kanałów C2 i kamuflaż ruchu, więc „allow-all egress” w chmurze to proszenie się o kłopoty.

5) Przygotuj proces IR „pod cloud-native”

  • Playbook na incydent w K8s (izolacja node/pod, snapshoty, artefakty runtime, eksport audit logs).
  • Zbieraj dane, które przetrwają anti-forensics (telemetria runtime, logi z warstwy kontrolnej chmury).

Różnice / porównania z innymi przypadkami

  • VoidLink vs „klasyczne Linux malware”: tu mamy platformę C2 + post-exploitation z pluginami, dashboardem operatorskim i adaptacją do cloud/K8s – to bardziej „Linuxowy odpowiednik” ekosystemów znanych z Windows.
  • Inspiracje Cobalt Strike: podobieństwo jest jawne w warstwie API/wtyczek (BOF-like). To ważne, bo pokazuje przenoszenie sprawdzonych wzorców ofensywnych do chmury opartej o Linuksa.
  • AI-assisted malware (nowa jakość): Check Point argumentuje, że wcześniejsze „AI malware” bywało niskiej jakości lub wtórne, a VoidLink ma być pierwszym dobrze udokumentowanym przypadkiem, gdzie AI przyspieszyło budowę złożonego, oryginalnego frameworka przy udziale kompetentnego twórcy.

Podsumowanie / kluczowe wnioski

VoidLink to sygnał ostrzegawczy w dwóch wymiarach: (1) technicznie – bo łączy cloud awareness, pluginową architekturę i rootkity (LD_PRELOAD/LKM/eBPF) z wielokanałowym C2; (2) metodycznie – bo według Check Point znacząca część wytwarzania mogła być „napędzana” przez podejście agentowe (SDD + sprinty + automatyzacja), co skraca cykl tworzenia ofensywnych platform.

Dobra wiadomość: w momencie publikacji analiz (styczeń 2026) nie ma twardych dowodów na szerokie użycie w atakach. Zła: projekt wygląda jak „prawie gotowy” i może zostać szybko dopięty do kampanii szpiegowskich, kradzieży sekretów w chmurze lub działań supply-chain.

Źródła / bibliografia

  1. Check Point Research – „Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework” (13.01.2026). (Check Point Research)
  2. Sysdig Threat Research – „VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits” (16.01.2026). (sysdig.com)
  3. Check Point Research – „VoidLink: Evidence That the Era of Advanced AI-Generated Malware Has Begun” (20.01.2026). (Check Point Research)
  4. The Hacker News – „VoidLink Linux Malware Framework Built with AI Assistance Reaches 88,000 Lines of Code” (21.01.2026). (The Hacker News)
  5. SecurityWeek – „VoidLink Linux Malware Framework Targets Cloud Environments” (15.01.2026). (SecurityWeek)

ChainLeak w Chainlit: dwie luki (CVE-2026-22218 i CVE-2026-22219) mogą wyciekać pliki, sekrety i dane z infrastruktury AI

Wprowadzenie do problemu / definicja luki

Chainlit to popularny, otwartoźródłowy framework w Pythonie do budowania aplikacji konwersacyjnych (chatbotów i interfejsów dla agentów/LLM), często integrowany z ekosystemem narzędzi LLM. Zafran Labs opisał dwie podatności wysokiej wagi (zbiorczo nazywane „ChainLeak”), które w pewnych konfiguracjach mogą prowadzić do ujawnienia plików z serwera oraz do SSRF (Server-Side Request Forgery), czyli wykonywania żądań sieciowych z wnętrza serwera aplikacji do zasobów wewnętrznych (w tym endpointów metadanych chmurowych).

W skrócie

  • Dotknięte wersje: Chainlit < 2.9.4 (łatka w 2.9.4).
  • CVE-2026-22218 (arbitrary file read): uwierzytelniony klient może doprowadzić do skopiowania wskazanego pliku do swojej „sesji” i następnie pobrać go po identyfikatorze (m.in. przez endpoint /project/file/<chainlitKey>).
  • CVE-2026-22219 (SSRF): w konfiguracji z backendem warstwy danych opartym o SQLAlchemy uwierzytelniony klient może podać kontrolowany url, który serwer pobierze metodą HTTP GET, co umożliwia sięgnięcie do usług wewnętrznych i/lub metadanych chmurowych.
  • Skutek biznesowy: wyciek sekretów (np. kluczy API), danych aplikacji i potencjalnie danych innych użytkowników w środowiskach współdzielonych.

Kontekst / historia / powiązania

W aplikacjach opartych o LLM typowe „stare” klasy podatności webowych (IDOR, SSRF, file read) są szczególnie groźne, bo te systemy:

  • często działają internet-facing (boty wsparcia, portale dla klientów),
  • trzymają sekrety do modeli/agentów (API keys), konektory do baz danych i zasobów firmowych,
  • bywają wielowarstwowe (UI → orkiestracja → narzędzia → dane), co zwiększa powierzchnię ataku.

Zafran wskazuje, że podatności zostały potwierdzone w rzeczywistych, publicznie dostępnych wdrożeniach.

Analiza techniczna / szczegóły luki

CVE-2026-22218 — Arbitrary File Read przez „element update flow”

Z opisu podatności wynika następujący łańcuch:

  1. Uwierzytelniony klient wysyła spreparowany „Element” z kontrolowaną ścieżką (path).
  2. Serwer kopiuje wskazany plik do obszaru sesji atakującego.
  3. Serwer zwraca identyfikator (np. chainlitKey), który pozwala pobrać treść pliku przez API (w opisie pada ścieżka /project/file/<chainlitKey>).

Dlaczego to jest groźne w AI-app?
Jeśli proces Chainlit ma uprawnienia do odczytu wrażliwych plików (konfiguracje, klucze, cache, logi), atakujący może sukcesywnie „wydzierać” informacje z hosta.

CVE-2026-22219 — SSRF przez url w elementach (SQLAlchemy data layer)

Ten wektor dotyczy sytuacji, gdy aplikacja używa backendu warstwy danych opartego o SQLAlchemy. Mechanizm (z perspektywy opisu) wygląda tak:

  1. Atakujący (uwierzytelniony) tworzy element z kontrolowanym polem url.
  2. Logika serwera pobiera zawartość spod tego URL (HTTP GET) „z wnętrza” infrastruktury serwera.
  3. Odpowiedź może zostać zapisana w skonfigurowanym storage providerze, co ułatwia eksfiltrację.

W praktyce SSRF bywa wykorzystywane do:

  • skanowania usług wewnętrznych (panele admin, Redis/Elastic, wewnętrzne API),
  • uderzenia w cloud metadata endpoints (np. poświadczenia ról/instancji), co bywa początkiem eskalacji w chmurze.

Praktyczne konsekwencje / ryzyko

Najbardziej „nośne” scenariusze ryzyka w kontekście Chainlit/LLM to:

  • Wyciek sekretów i konfiguracji (zmienne środowiskowe, pliki .env, konfiguracje konektorów) – Zafran wskazuje m.in. możliwość odczytu /proc/self/environ jako przykład pozyskania wrażliwych wartości.
  • Wyciek danych aplikacyjnych: logi, cache, artefakty sesji, pliki tymczasowe – szczególnie jeśli serwer pracuje na wspólnym hoście/klastrze i ma szerokie uprawnienia.
  • Ryzyko w środowiskach multi-tenant: jeśli aplikacja przechowuje treści promptów/odpowiedzi w warstwach cache/plikach, file read może prowadzić do ujawnienia danych innych użytkowników.
  • SSRF jako „pomost” do chmury: dostęp do metadanych instancji lub wewnętrznych usług może skończyć się przejęciem uprawnień i ruchem bocznym (lateral movement).

Warto podkreślić: oba CVE wymagają uwierzytelnionego klienta, więc najczęściej nie jest to „drive-by” bez logowania. Z drugiej strony, w realnych wdrożeniach często istnieją konta o niskim poziomie zaufania (np. self-service), integracje SSO, konta testowe lub źle skonfigurowane role — i to zwykle wystarcza, by podatność stała się praktycznie wykorzystywalna.

Rekomendacje operacyjne / co zrobić teraz

1) Patch management (najważniejsze)

  • Zaktualizuj Chainlit do wersji 2.9.4 lub nowszej (to wersja wskazana jako naprawiająca problem).

2) Zmniejsz skutki, jeśli nie możesz patchować natychmiast

  • Ogranicz ekspozycję: jeśli to możliwe, zdejmij instancję z publicznego internetu (VPN / allowlista / reverse proxy z MFA). (To dobra praktyka dla paneli LLM i aplikacji wewnętrznych, nawet niezależnie od tej konkretnej luki.)
  • Zasada najmniejszych uprawnień dla procesu: uruchamiaj usługę na użytkowniku systemowym bez dostępu do katalogów z sekretami; rozważ kontenery z read-only FS tam, gdzie da się. (Zmniejsza to realny „zasięg” arbitrary file read.)
  • Egress filtering dla serwera (firewall/SG/NACL): ogranicz ruch wychodzący tylko do niezbędnych domen/usług (to kluczowe w obronie przed SSRF).
  • Ochrona metadanych chmurowych: w zależności od chmury i architektury — blokuj dostęp do adresów metadanych z poziomu aplikacji lub wymagaj nowszych mechanizmów autoryzacji (np. tokenów dla metadanych), by SSRF nie mógł pobrać poświadczeń „za darmo”.

3) Detekcja i monitoring

  • Przejrzyj logi pod kątem nietypowych żądań związanych z tworzeniem/aktualizacją „elementów” oraz pobieraniem plików po identyfikatorach.
  • Monitoruj nietypowy ruch wychodzący HTTP z hostów aplikacji (kierunki wewnętrzne, nietypowe hosty, próby dostępu do metadanych).

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

To dobry przykład, że „AI framework” nie musi mieć „AI-specyficznej” podatności, by doprowadzić do poważnego incydentu. W praktyce:

  • Arbitrary file read w aplikacji LLM to często natychmiastowy wyciek: kluczy API do modeli, konfiguracji narzędzi (tooling), poświadczeń do baz i integracji.
  • SSRF w środowisku chmurowym jest klasycznym wektorem do pozyskania tokenów/poświadczeń i eskalacji.

Wniosek operacyjny: traktuj warstwę aplikacji LLM jak każdą krytyczną aplikację webową — z pełnym zestawem kontroli (hardening, segmentacja, egress, least privilege), bo „nowoczesny” stos technologiczny dziedziczy „klasyczne” ryzyka.

Podsumowanie / kluczowe wnioski

  • Chainlit < 2.9.4 jest narażony na dwie podatności (CVE-2026-22218, CVE-2026-22219), które mogą prowadzić do wycieku plików i/lub SSRF.
  • W realnych wdrożeniach AI ryzyko jest podbite przez obecność sekretów (API keys), konektorów do danych firmowych i częstą ekspozycję usług na internet.
  • Najszybsza i najpewniejsza redukcja ryzyka: upgrade do 2.9.4+, a dodatkowo ograniczenie egress i uprawnień procesu.

Źródła / bibliografia

  1. SecurityWeek — opis podatności i kontekst ekspozycji instancji w internecie. (SecurityWeek)
  2. Zafran Labs — „ChainLeak” (analiza techniczna, scenariusze eksfiltracji i wpływ na AI stack). (Zafran Security)
  3. GitHub Advisory Database — CVE-2026-22218 (arbitrary file read, warunki i wersje). (GitHub)
  4. GitHub Advisory Database — CVE-2026-22219 (SSRF, warunki dot. SQLAlchemy, wersje). (GitHub)
  5. Tenable — opis CVE-2026-22218 i przykładowe ścieżki/endpointy eksfiltracji. (Tenable®)

Krytyczne luki w serwerach MCP: SSRF, RCE i ryzyko przejęć chmury w ekosystemie agentów AI (Microsoft, Anthropic)

Wprowadzenie do problemu / definicja luki

Model Context Protocol (MCP) to standard łączący modele językowe i agentów AI z narzędziami (np. repozytoriami Git, systemem plików, usługami chmurowymi czy konwerterami dokumentów). W praktyce MCP „wystawia” funkcje (tools), które agent może wywoływać w odpowiedzi na polecenia użytkownika… albo na polecenia przemycone w danych wejściowych (np. w README, stronie WWW, pliku).

Nowy problem nie polega wyłącznie na tym, że „gdzieś jest błąd”. Chodzi o to, że serwery MCP często działają jako uprzywilejowane pośredniki: mają dostęp do sieci, plików, tokenów, repozytoriów, a czasem wręcz do zasobów chmurowych. Jeśli da się nimi sterować (bez ograniczeń) albo jeśli agent da się nakłonić do uruchomienia sekwencji narzędzi — powstaje prosta ścieżka do SSRF, kradzieży sekretów i RCE.

W skrócie

  • Badacze opisali poważne ryzyka w popularnych serwerach MCP: SSRF w Microsoft MarkItDown MCP oraz łańcuch prowadzący do RCE w oficjalnych serwerach MCP Anthropic (Git + Filesystem).
  • W przypadku MarkItDown problemem jest możliwość pobierania dowolnych URI bez ograniczeń, co otwiera drogę do SSRF i np. odczytu metadanych instancji w chmurze.
  • W przypadku Anthropic zidentyfikowano trzy luki (CVE-2025-68145 / -68143 / -68144), które można łączyć z innymi narzędziami MCP, by doprowadzić do wykonania kodu.
  • Kluczowa lekcja: kompozycja narzędzi (tool chaining) + pośrednictwo agentów = ryzyko wykraczające poza „pojedynczą podatność” — to problem architektoniczny.

Kontekst / historia / powiązania

W artykule Dark Reading (20 stycznia 2026) podkreślono, że MCP powstał jako otwarty standard, a kwestie bezpieczeństwa w dużej mierze pozostawiono implementatorom. Efekt: część serwerów MCP „dowiozła funkcjonalność”, ale bez twardych barier bezpieczeństwa.

Microsoft równolegle publikuje materiały o zabezpieczaniu serwerów MCP (np. autentykacja/autoryzacja JWT, dobre praktyki dla wdrożeń oraz zarządzanie dostępem). To ważny sygnał: dostawcy widzą, że MCP szybko staje się infrastrukturą krytyczną, a nie tylko „wtyczką do LLM”.

Analiza techniczna / szczegóły luki

1) Microsoft MarkItDown MCP: SSRF przez „nieograniczone URI”

Z opisu wynika, że MarkItDown MCP przyjmuje od użytkownika/klienta URI wskazujące źródło pliku do konwersji i pobiera je bez mechanizmów ograniczających (brak sensownego allowlist/denylist, brak twardej walidacji docelowych adresów). To klasyczny wzorzec SSRF, tylko osadzony w nowym workflow: „agent → narzędzie MCP → sieć”.

Najbardziej niebezpieczny wariant to środowisko chmurowe: gdy serwer działa np. na instancji AWS EC2, możliwe jest odpytywanie usługi metadanych instancji (IMDS) i pozyskanie tymczasowych poświadczeń (access key/secret/session token) przypiętych do roli IAM. Dark Reading wskazuje też na różnicę odporności IMDSv2 vs IMDSv1.

Wniosek techniczny: w świecie MCP SSRF nie jest „tylko SSRF-em” — to często most do przejęcia chmury, bo serwer MCP bywa uruchamiany blisko sekretów, tokenów i metadanych infrastruktury.

2) Anthropic Git MCP + Filesystem MCP: łańcuch do RCE

Opisane błędy w oficjalnym Git MCP (mcp-server-git) obejmują m.in.:

  • obejście walidacji ścieżek (CVE-2025-68145),
  • możliwość inicjalizacji repozytorium w dowolnej lokalizacji (CVE-2025-68143),
  • wstrzyknięcie argumentów/niebezpieczne obchodzenie się z parametrami w kontekście git_diff (CVE-2025-68144).

Kluczowe jest jednak to, jak dochodzi do RCE: podatności stają się groźne, gdy agent potrafi wykonać sekwencję działań przez różne narzędzia MCP (np. Git + Filesystem). Dark Reading opisuje scenariusz, w którym atakujący przemyca instrukcje poprzez indirect prompt injection (np. „złośliwe README”), a następnie agent wykonuje działania prowadzące do przygotowania repozytorium i uruchomienia poleceń (np. przez mechanizmy git związane z filtrami/atrybutami).

Wniosek techniczny: tu nie chodzi o „magiczne RCE w LLM”, tylko o bardzo klasyczny łańcuch: błąd kontroli ścieżek + możliwość zapisu plików + uruchomienie procesu (git) z podatnymi parametrami — tyle że zautomatyzowany przez agenta.

Praktyczne konsekwencje / ryzyko

Najbardziej realistyczne scenariusze nadużyć w organizacjach:

  • Kradzież sekretów i eskalacja w chmurze: SSRF do IMDS / usług metadanych, odczyt tokenów, a potem przejęcie zasobów (storage, bazy, pipeline CI/CD).
  • RCE na stacjach dev / runnerach CI: jeśli MCP serwery (Git/Filesystem) działają lokalnie lub w środowiskach build, skutkiem może być przejęcie repozytoriów, podmiana artefaktów, wstrzyknięcia do łańcucha dostaw.
  • „Confused deputy” w architekturach pośredniczących: serwer MCP jako proxy do innych API może zostać użyty do uzyskania niezamierzonego dostępu, jeśli źle zaprojektowano autoryzację i zgody.
  • Ataki przez dane, nie przez użytkownika: indirect prompt injection sprawia, że bodźcem jest treść (plik/WWW), a nie „zły użytkownik w czacie”. To zmienia monitoring i model zagrożeń.

Rekomendacje operacyjne / co zrobić teraz

Twarde ograniczenia dla SSRF (priorytet #1)

  • Wprowadź allowlist schematów i hostów dla narzędzi pobierających zasoby (np. tylko https do zatwierdzonych domen/bucketów).
  • Zablokuj dostęp sieciowy z procesu MCP do adresów link-local i usług metadanych (np. 169.254.169.254), a także do prywatnych zakresów, jeśli nie są potrzebne (egress filtering).
  • W chmurze wymuś IMDSv2 tam, gdzie to możliwe (zmniejsza podatność na część klas SSRF).

Minimalizacja uprawnień i „blast radius”

  • Uruchamiaj serwery MCP w izolacji (kontener, sandbox, osobna tożsamość) i dawaj im tylko minimalne uprawnienia (RBAC/least privilege).
  • Rozdziel narzędzia „read” i „write”; operacje zapisu/niszczenia wymagaj jako jawnie zatwierdzane (human-in-the-loop dla krytycznych akcji).

Uwierzytelnianie i autoryzacja (bez tego MCP to „otwarta brama”)

  • Zaimplementuj authn/authz dla MCP (np. JWT/OAuth) oraz kontroluj, kto może wywoływać które tool’e. Microsoft pokazuje podejście z JWT i praktycznymi wzorcami wdrożeniowymi dla serwerów MCP.
  • Jeśli wystawiasz MCP przez warstwę zarządzania API, rozważ centralne egzekwowanie polityk dostępowych (klucze/subskrypcje, tokeny, walidacja) i spójny audyt wywołań.

Ochrona przed indirect prompt injection i „tool chaining”

  • Traktuj treści zewnętrzne (WWW/pliki) jako dane nieufne i projektuj agenta tak, by oddzielać „instrukcje” od „kontekstu”.
  • Dodaj reguły: agent nie może wykonywać operacji wysokiego ryzyka na podstawie niezweryfikowanej treści (np. z README). W praktyce: polityki wykonywania narzędzi, klasyfikacja ryzyka tool’i, oraz walidacje parametrów po stronie serwera MCP.

Różnice / porównania z innymi przypadkami

To nie jest „kolejna podatność w web appce”.
W klasycznym SSRF atakujący zwykle bije w endpoint aplikacji. W MCP często bije w narzędzie uruchamiane przez agenta, które działa z innym poziomem zaufania i uprawnień.

To nie jest też „tylko prompt injection”.
Prompt injection jest wyzwalaczem, ale realne szkody wynikają z tego, że agent ma dostęp do narzędzi o mocy porównywalnej z kontem uprzywilejowanym (chmura, system plików, repo). To przesuwa ciężar obrony na: tożsamość, granice sieciowe, walidację parametrów i polityki wykonywania narzędzi.

Podsumowanie / kluczowe wnioski

  • MCP przyspiesza budowę agentów AI, ale jednocześnie tworzy nową, bardzo „twardą” powierzchnię ataku: SSRF → sekrety → przejęcie chmury oraz kompozycja narzędzi → RCE.
  • Największe ryzyko wynika z braku ograniczeń na wejściu (URI/ścieżki/argumenty) i z faktu, że serwer MCP działa jako uprzywilejowany wykonawca.
  • Skuteczna obrona to kombinacja: walidacji + izolacji + least privilege + kontroli tożsamości + polityk wykonywania narzędzi (a nie tylko „lepszego promptu”).

Źródła / bibliografia

  1. Dark Reading — „Microsoft & Anthropic MCP Servers At Risk of RCE, Cloud Takeovers” (20.01.2026). (Dark Reading)
  2. The Register — opis podatności i CVE w Anthropic Git MCP (20.01.2026). (The Register)
  3. Microsoft Learn — „Foundry MCP Server best practices and security guidance” (aktualizacje i governance). (Microsoft Learn)
  4. Microsoft TechCommunity — „It’s time to secure your MCP servers. Here’s how.” (JWT, podejście wdrożeniowe). (TECHCOMMUNITY.MICROSOFT.COM)
  5. Model Context Protocol — „Security Best Practices” (ryzyka i mitigacje specyficzne dla MCP, m.in. confused deputy). (Model Context Protocol)