Archiwa: AI - Strona 7 z 88 - Security Bez Tabu

Krytyczna luka RCE w Flowise: złośliwy import chatflow może przejąć serwer

Cybersecurity news

Wprowadzenie do problemu / definicja

Flowise to popularna platforma open source wykorzystywana do budowy agentów AI, workflow opartych na dużych modelach językowych oraz integracji z narzędziami zewnętrznymi. Najnowsze analizy bezpieczeństwa wskazują jednak, że sposób obsługi mechanizmu Custom MCP może prowadzić do krytycznej podatności typu zdalne wykonanie kodu (RCE), umożliwiającej przejęcie serwera.

Problem dotyczy scenariusza, w którym uwierzytelniony użytkownik importuje spreparowany plik chatflow. Taki pozornie zwykły plik konfiguracyjny może zawierać parametry prowadzące do uruchomienia złośliwych poleceń w środowisku hostującym Flowise.

W skrócie

  • Podatność została opisana jako CVE-2026-40933.
  • Atak ma charakter one-click RCE i wymaga nakłonienia zalogowanego użytkownika do importu złośliwego chatflow.
  • Źródłem problemu jest obsługa Custom MCP, zwłaszcza konfiguracji wykorzystujących transport stdio.
  • Publicznie dostępny kod PoC zwiększa ryzyko szybkiego wykorzystania luki w realnych środowiskach.
  • Najbardziej zagrożone są self-hostowane instancje Flowise z dostępem do sekretów, usług wewnętrznych i funkcji importu workflow.

Kontekst / historia

Wraz ze wzrostem popularności agentów AI rośnie także znaczenie bezpieczeństwa warstw integracyjnych, które łączą modele językowe z lokalnymi procesami, usługami API i zasobami infrastrukturalnymi. Model Context Protocol zyskuje na znaczeniu jako standard komunikacji między aplikacjami AI a narzędziami zewnętrznymi, ale jednocześnie poszerza powierzchnię ataku.

Flowise należy do grupy platform, które upraszczają tworzenie złożonych przepływów pracy oraz gotowych integracji. To właśnie ta wygoda staje się jednak ryzykowna, gdy aplikacja pozwala importować gotowe workflow z zewnętrznych źródeł. W takim modelu plik konfiguracyjny przestaje być jedynie neutralnym opisem logiki i może stać się nośnikiem niebezpiecznych instrukcji.

Opisana luka wpisuje się w szerszy trend problemów bezpieczeństwa wokół narzędzi agentowych i implementacji MCP. Szczególnie niebezpieczne okazują się sytuacje, w których warstwa integracyjna może uruchamiać lokalne procesy, a walidacja parametrów wejściowych jest niepełna lub opiera się na łatwych do obejścia mechanizmach filtrowania.

Analiza techniczna

Kluczowym elementem podatności jest sposób, w jaki Flowise obsługuje Custom MCP w konfiguracjach korzystających z transportu stdio. Mechanizm ten pozwala aplikacji uruchamiać lokalny proces i komunikować się z nim przez standardowe wejście oraz wyjście. Funkcjonalnie daje to dużą elastyczność, ponieważ umożliwia szybkie podłączanie własnych serwerów MCP i narzędzi uruchamianych przez lokalne binaria, interpretery czy menedżery pakietów.

Z perspektywy bezpieczeństwa tworzy to jednak bezpośrednie połączenie między konfiguracją dostarczoną przez użytkownika a wykonywaniem poleceń systemowych. Jeśli aplikacja nie stosuje ścisłej listy dozwolonych procesów, odpowiednio nie separuje argumentów, nie wymusza bezpiecznej serializacji oraz pozwala na import gotowych workflow, wówczas atakujący może przygotować chatflow prowadzący do wykonania nieautoryzowanego kodu.

Istotne jest również to, że scenariusz ataku nie wymaga od ofiary zaawansowanej interakcji. W praktyce wystarcza import złośliwego pliku przez zalogowanego operatora. To obniża próg wejścia dla napastnika, ponieważ spreparowany plik może zostać przedstawiony jako legalny szablon automatyzacji, integracji AI lub gotowy komponent usprawniający pracę zespołu.

Badacze zwrócili także uwagę, że częściowe zabezpieczenia można obchodzić. Jeżeli mechanizmy ochronne opierają się głównie na blacklistingu komend lub prostym filtrowaniu wzorców wejściowych, architektura nadal pozostaje narażona na nadużycia. W praktyce oznacza to, że sam model uruchamiania lokalnych procesów z poziomu warstwy integracyjnej stanowi istotne ryzyko projektowe.

Konsekwencje / ryzyko

Skuteczna eksploatacja luki może prowadzić do pełnego przejęcia środowiska, w którym działa Flowise. W zależności od architektury wdrożenia skutki mogą objąć zarówno sam kontener aplikacji, jak i szerszą infrastrukturę sieciową.

  • przejęcie hosta lub kontenera uruchamiającego Flowise,
  • dostęp do kluczy API, tokenów i innych sekretów zapisanych w konfiguracji,
  • odczyt, modyfikację lub usunięcie lokalnych plików,
  • ruch boczny do innych systemów dostępnych z poziomu podatnej instancji,
  • manipulację agentami AI i wynikami ich działania,
  • utrwalenie obecności napastnika w środowisku.

Najwyższe ryzyko dotyczy organizacji, które wystawiają panel Flowise do internetu, przechowują w nim poświadczenia do usług chmurowych i źródeł danych oraz pozwalają użytkownikom importować workflow pochodzące spoza organizacji. Szczególnie narażone są środowiska współdzielone, gdzie wielu operatorów korzysta z jednego panelu i ufa gotowym szablonom.

Rekomendacje

Podatność należy traktować jako problem wysokiego priorytetu operacyjnego. Organizacje korzystające z Flowise powinny jak najszybciej ograniczyć ekspozycję i wdrożyć działania naprawcze.

  • Niezwłocznie zaktualizować Flowise do wersji zawierającej poprawki bezpieczeństwa.
  • Zweryfikować, czy w środowisku nie działają starsze, testowe lub zapomniane instancje aplikacji.
  • Tymczasowo wyłączyć lub silnie ograniczyć funkcję importu chatflow oraz użycie Custom MCP, jeśli nie są niezbędne.
  • Ograniczyć dostęp do panelu administracyjnego wyłącznie przez VPN, segmentację sieci lub dodatkową kontrolę tożsamości.
  • Uruchamiać Flowise w odizolowanym środowisku o minimalnych uprawnieniach i bez zbędnego dostępu do zasobów hosta.
  • Wdrożyć allowlistę dozwolonych procesów, binariów i parametrów uruchamianych przez integracje MCP.
  • Monitorować logi pod kątem importu nowych workflow, nietypowych procesów potomnych, wywołań powłoki i zmian konfiguracyjnych.
  • Przeprowadzić rotację sekretów, tokenów i kluczy API, jeśli istnieje podejrzenie kompromitacji.
  • Traktować wszystkie importowane workflow jak potencjalnie niebezpieczny kod, a nie zwykłe pliki konfiguracyjne.

Dodatkowo warto przyjąć zasadę, że każdy komponent MCP zdolny do uruchamiania lokalnych procesów powinien być klasyfikowany jako krytyczna powierzchnia ataku. Oznacza to potrzebę twardej izolacji, jawnego modelu zaufania i rygorystycznej kontroli konfiguracji.

Podsumowanie

Luka CVE-2026-40933 w Flowise pokazuje, że środowiska AI stają się pełnoprawnym celem ataków infrastrukturalnych. Problem nie ogranicza się wyłącznie do pojedynczego błędu implementacyjnego, lecz wynika z niebezpiecznego połączenia funkcji integracyjnych, uruchamiania lokalnych procesów i zaufania do importowanych workflow.

Publicznie dostępny PoC dodatkowo zwiększa prawdopodobieństwo szybkiej weaponizacji. Dla zespołów bezpieczeństwa to wyraźny sygnał, że platformy agentowe AI wymagają takiego samego poziomu hardeningu, segmentacji i monitoringu jak klasyczne systemy o krytycznym znaczeniu dla organizacji.

Źródła

  1. Infosecurity Magazine — https://www.infosecurity-magazine.com/news/flowise-mcp-rce-poc/
  2. Obsidian Security: 1-Click RCE in Flowise (CVE-2026-40933): When Is stdio MCP Actually a Vulnerability? — https://www.obsidiansecurity.com/blog/when-is-stdio-mcp-actually-a-vulnerability
  3. CSO Online: Flowise’s MCP implementation can run ghost commands — https://www.csoonline.com/article/4179309/flowises-mcp-implementation-can-run-ghost-commands.html
  4. FlowiseAI Documentation: Tools & MCP — https://docs.flowiseai.com/tutorials/tools-and-mcp
  5. Cloud Security Alliance: Flowise CVSS 10.0 RCE: AI Agent Builders Under Attack — https://labs.cloudsecurityalliance.org/research/csa-research-note-flowise-mcp-rce-exploitation-20260409-csa/

Atak supply chain na npm uderza w użytkowników OpenAI Codex i prowadzi do kradzieży tokenów

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem narzędzi programistycznych opartych na sztucznej inteligencji staje się coraz częstszym celem ataków na łańcuch dostaw oprogramowania. Najnowszy incydent pokazuje, że zagrożenie nie dotyczy już wyłącznie prostych kampanii typosquattingowych, ale również pakietów open source, które sprawiają wrażenie użytecznych i aktywnie rozwijanych.

W tym przypadku złośliwa funkcjonalność została osadzona w pakiecie npm powiązanym z interfejsem dla OpenAI Codex. Celem atakujących była kradzież lokalnie przechowywanych tokenów uwierzytelniających, co mogło umożliwić przejęcie sesji i dalsze działania w imieniu ofiar.

W skrócie

Badacze bezpieczeństwa ujawnili kampanię supply chain, w której pakiet npm o nazwie codexui-android zawierał mechanizm wykradający dane z lokalnego pliku uwierzytelnienia OpenAI Codex. Złośliwy kod miał odczytywać zawartość pliku auth.json, a następnie przesyłać tokeny dostępu, odświeżania oraz identyfikatory kont na zewnętrzny serwer kontrolowany przez napastnika.

Problem nie ogranicza się wyłącznie do samego pakietu npm. Według dostępnych ustaleń ryzyko obejmowało również aplikacje mobilne wykorzystujące ten komponent jako element zaplecza uruchamianego w środowisku sandboxowym. To kolejny sygnał, że narzędzia AI dla deweloperów stają się pełnoprawnym celem zaawansowanych kampanii wymierzonych w zaufanie do ekosystemu open source.

Kontekst / historia

Na tle typowych incydentów w npm ten przypadek wyróżnia się tym, że nie opierał się na nazwie łudząco podobnej do popularnej biblioteki. Zamiast tego wykorzystano funkcjonalny komponent promowany jako zdalny, webowy interfejs dla OpenAI Codex. Taki model działania zwiększa prawdopodobieństwo adopcji przez użytkowników i jednocześnie utrudnia szybkie rozpoznanie zagrożenia.

Z dostępnych informacji wynika, że złośliwe zmiany nie musiały być obecne od początku istnienia projektu. To wpisuje się w dobrze znany schemat ataków supply chain, w którym napastnik najpierw buduje reputację pakietu, a dopiero później dodaje szkodliwy ładunek do artefaktu publikowanego w rejestrze.

Znaczenie incydentu wzmacnia również fakt, że nowoczesne narzędzia agentowe i środowiska wspierające programowanie z użyciem AI często przechowują dane logowania lokalnie. Ma to ułatwiać korzystanie z CLI, IDE czy aplikacji mobilnych, ale jednocześnie tworzy nową powierzchnię ataku, w której przejęcie jednej zależności może otworzyć drogę do kompromitacji uprawnień użytkownika.

Analiza techniczna

Technicznie atak polegał na odczytaniu lokalnego pliku uwierzytelnienia OpenAI Codex, zwykle przechowywanego jako ~/.codex/auth.json, a następnie na eksfiltracji jego zawartości do zewnętrznego endpointu. Wśród przechwytywanych danych znajdowały się m.in. access token, refresh token, id token oraz identyfikator konta.

Najpoważniejszym elementem tego scenariusza jest wykorzystanie refresh tokena. Taki sekret może umożliwić odtwarzanie lub przedłużanie sesji bez ponownego pozyskiwania poświadczeń od użytkownika. W praktyce oznacza to ryzyko utrzymania długotrwałego, trudnego do wykrycia dostępu do usług powiązanych z kontem ofiary.

Ważny jest także kontekst mobilny. Opisywana kampania obejmowała aplikacje na Androida, które uruchamiały komponent npm wewnątrz odizolowanego środowiska Linux/Node.js osadzonego w aplikacji. Oznacza to, że podstawowa analiza samego pakietu APK mogła nie ujawnić pełnego zachowania, jeśli kluczowa logika była zależna od pakietów pobieranych lub aktualizowanych poza głównym artefaktem aplikacji.

Incydent pokazuje też szerszy problem kontroli zaufania w open source. Repozytorium źródłowe może wyglądać niegroźnie, podczas gdy złośliwe zmiany pojawiają się wyłącznie w pakiecie opublikowanym do rejestru. Dla organizacji oznacza to konieczność porównywania kodu źródłowego z faktycznie wdrażanym artefaktem, a nie polegania wyłącznie na publicznym repozytorium.

Konsekwencje / ryzyko

Skutki takiego incydentu mogą być poważne, ponieważ ofiarami są często deweloperzy posiadający szerokie uprawnienia do repozytoriów, systemów CI/CD, sekretów środowiskowych i zasobów chmurowych. Przejęcie tokenów związanych z OpenAI Codex może stać się punktem wyjścia do dalszej eskalacji uprawnień lub ruchu bocznego w środowisku organizacji.

Dodatkowym problemem jest trudność wykrycia nadużyć. Jeżeli napastnik korzysta z prawidłowych tokenów, jego aktywność może wyglądać jak legalne działanie autoryzowanego użytkownika. W środowiskach enterprise zwiększa to ryzyko wycieku kodu źródłowego, przejęcia danych organizacyjnych i nieautoryzowanego użycia zasobów API.

Atak pokazuje również, że narzędzia AI dla programistów należy traktować jak infrastrukturę wysokiego ryzyka. Często mają one dostęp do lokalnego systemu plików, terminala, sekretów i projektów, więc kompromitacja jednego komponentu może mieć znacznie poważniejsze konsekwencje niż incydent w zwykłej aplikacji użytkowej.

Rekomendacje

Organizacje i użytkownicy, którzy mogli korzystać z podejrzanego pakietu lub aplikacji powiązanych z tym łańcuchem, powinni założyć, że tokeny OpenAI Codex mogły zostać skompromitowane. Konieczne jest natychmiastowe wylogowanie aktywnych sesji, unieważnienie tokenów, ponowna autoryzacja oraz przegląd historii aktywności konta.

  • Zidentyfikować systemy, na których instalowano pakiet codexui-android lub powiązane aplikacje mobilne.
  • Usunąć podejrzane komponenty i przeprowadzić analizę powłamaniową na stacjach roboczych deweloperów.
  • Wymusić rotację tokenów, kluczy API i innych sekretów dostępnych z poziomu potencjalnie skompromitowanego środowiska.
  • Monitorować ruch wychodzący pod kątem połączeń do nieautoryzowanych domen i anomalii behawioralnych.
  • Skanować zależności npm nie tylko pod kątem reputacji, ale również zachowania runtime i różnic między repozytorium a publikowaną paczką.
  • Stosować pinning wersji oraz wewnętrzne mirrorowanie i zatwierdzanie pakietów przed wdrożeniem.
  • Ograniczać czas życia oraz zakres uprawnień tokenów używanych przez narzędzia AI i integracje deweloperskie.
  • Traktować lokalne pliki z poświadczeniami z taką samą ostrożnością jak hasła, klucze prywatne i inne sekrety.

Zespoły AppSec i DevSecOps powinny dodatkowo rozszerzyć model zagrożeń o aplikacje agentowe, rozszerzenia IDE, narzędzia CLI oraz mobilne komponenty developerskie. Tradycyjne podejście do bezpieczeństwa endpointów nie zawsze obejmuje takie scenariusze w wystarczającym stopniu.

Podsumowanie

Atak wymierzony w użytkowników OpenAI Codex potwierdza, że narzędzia AI stały się atrakcyjnym celem operacji supply chain. Najważniejszą lekcją z tego incydentu jest to, że nawet funkcjonalny i rozwijany pakiet nie musi być bezpieczny, a lokalne pliki uwierzytelniające mogą stać się cennym łupem dla napastników.

W praktyce bezpieczeństwo pracy z narzędziami AI wymaga dziś podobnego rygoru jak ochrona pipeline’ów CI/CD, sekretów chmurowych i repozytoriów kodu. Organizacje korzystające z agentów programistycznych powinny pilnie zweryfikować procedury związane z walidacją zależności, ochroną tokenów oraz monitorowaniem środowisk deweloperskich.

Źródła

  1. OpenAI Codex Authentication Tokens Stolen in codexui-android npm Supply Chain Attack
  2. Codex CLI and Sign in with ChatGPT | OpenAI Help Center
  3. OpenClaw Codex Claude AI Agent: Free Android Tools App – APK Info & Stats
  4. GitHub – OpenClawAndroid/openclaw-android-assistant
  5. Malicious npm Package Steals OpenAI Codex Tokens

ChatGPhish: jak podatność w mechanizmie podsumowań ChatGPT tworzy nową powierzchnię phishingową

Cybersecurity news

Wprowadzenie do problemu / definicja

ChatGPhish to technika ataku pokazująca, że zagrożenie w systemach generatywnej AI nie musi wynikać wyłącznie z samego modelu, ale także ze sposobu prezentowania odpowiedzi użytkownikowi. W opisywanym scenariuszu złośliwie przygotowana strona internetowa wpływa na treść podsumowania generowanego przez ChatGPT, a następnie prowadzi do wyświetlenia elementów, które mogą wyglądać na zaufane składniki interfejsu.

Problem staje się szczególnie niebezpieczny wtedy, gdy odpowiedź AI renderuje aktywne linki, zdalne obrazy lub komunikaty przypominające alerty bezpieczeństwa. Użytkownik odbiera je nie jako treść z obcej strony, lecz jako część odpowiedzi dostarczonej przez narzędzie, któremu ufa.

W skrócie

Badacze opisali atak, w którym ukryty ładunek osadzony na stronie WWW wpływa na wynik podsumowania tworzonego przez ChatGPT. Jeśli interfejs potraktuje wygenerowane elementy Markdown jako bezpieczne, użytkownik może zobaczyć klikalne odnośniki phishingowe, zdalnie pobierane obrazy, a nawet fałszywe komunikaty sugerujące pilne działania.

  • atak wykorzystuje pośrednie sterowanie modelem przez treść zewnętrzną,
  • zagrożenie obejmuje nie tylko model, ale również warstwę renderowania odpowiedzi,
  • interfejs AI może stać się nośnikiem socjotechniki i wycieku metadanych,
  • scenariusz rozszerza klasyczną powierzchnię ataku phishingowego.

Kontekst / historia

Indirect prompt injection od dłuższego czasu jest uznawany za jedno z najważniejszych zagrożeń dla aplikacji opartych na dużych modelach językowych. W odróżnieniu od bezpośrednich instrukcji wpisywanych przez użytkownika, tutaj polecenia są ukryte w źródłach zewnętrznych, takich jak strony internetowe, dokumenty, wiadomości lub repozytoria kodu.

Przypadek ChatGPhish jest jednak istotny z innego powodu. Nie chodzi wyłącznie o zmanipulowanie tego, co model „myśli” o analizowanej treści, ale o to, jak ta odpowiedź jest później wyświetlana. Gdy zewnętrznie kontrolowany przekaz zostaje opakowany w zaufany interfejs asystenta, skuteczność socjotechniki rośnie, ponieważ użytkownik rzadziej kwestionuje wiarygodność takiej prezentacji.

Analiza techniczna

Z technicznego punktu widzenia problem dotyczy całego łańcucha przetwarzania danych: pobrania zawartości strony, interpretacji jej przez model i renderowania końcowej odpowiedzi w aplikacji. Jeśli model uwzględni złośliwie przygotowane instrukcje lub składnię Markdown, a front-end wyrenderuje je jako aktywne elementy, treść pochodząca z nieufnego źródła może zacząć działać w ramach zaufanego interfejsu.

Najpoważniejsze skutki wynikają z kilku mechanizmów:

  • renderowania klikalnych linków w odpowiedzi asystenta,
  • automatycznego pobierania obrazów z serwerów kontrolowanych przez atakującego,
  • wyświetlania treści stylizowanych na alerty bezpieczeństwa lub komunikaty systemowe,
  • prezentowania kodów QR kierujących do zewnętrznych zasobów.

Taki model ataku nie wymaga klasycznej kampanii e-mailowej ani dostarczenia złośliwego załącznika. Wystarczy, że użytkownik poprosi asystenta AI o streszczenie odpowiednio przygotowanej strony internetowej. To oznacza, że zagrożenie może pojawić się podczas zwykłej pracy analitycznej, researchu, monitoringu OSINT czy przeglądu materiałów z internetu.

Konsekwencje / ryzyko

Ryzyko operacyjne dla organizacji jest istotne, zwłaszcza tam, gdzie narzędzia AI są wykorzystywane do analizy treści zewnętrznych. System nie musi wykonywać autonomicznych działań, aby stać się skutecznym kanałem dostarczania manipulacyjnych komunikatów.

  • Phishing w zaufanym kontekście – użytkownik widzi podejrzaną treść w oknie asystenta, a nie na jawnie podejrzanej stronie.
  • Wycieki metadanych – pobieranie obrazów może ujawnić informacje o środowisku ofiary, takie jak adres IP czy nagłówki HTTP.
  • Obejście części zabezpieczeń – kody QR i przekierowania na urządzenia mobilne mogą omijać ochronę wdrożoną na stacjach roboczych.
  • Większa skuteczność socjotechniki – treści generowane przez AI mają wysoki poziom wiarygodności percepcyjnej.
  • Trudniejsza detekcja – aktywność może wyglądać jak zwykłe korzystanie z legalnej aplikacji SaaS.

Dla zespołów bezpieczeństwa szczególnie problematyczne jest zacieranie granicy między treścią zewnętrzną a treścią pozornie autoryzowaną przez aplikację. Użytkownik może nie być w stanie odróżnić rzetelnej odpowiedzi systemu od efektu manipulacji źródłem wejściowym.

Rekomendacje

Organizacje korzystające z narzędzi AI powinny traktować funkcje podsumowywania stron i dokumentów jako operacje podwyższonego ryzyka. Ochrona musi obejmować zarówno warstwę techniczną, jak i procedury użycia.

Dla dostawców i zespołów produktowych kluczowe są następujące działania:

  • sanityzacja i neutralizacja elementów Markdown pochodzących z nieufnych źródeł,
  • blokowanie aktywnego renderowania linków i zdalnych obrazów w odpowiedziach opartych na zewnętrznych danych,
  • wyraźne oddzielanie cytatów ze źródeł od interpretacji modelu,
  • dodawanie ostrzeżeń przy treściach pochodzących bezpośrednio z analizowanej strony,
  • ograniczanie automatycznych połączeń do zasobów zewnętrznych.

Z perspektywy organizacji warto wdrożyć także praktyki operacyjne:

  • traktowanie podsumowań AI jako danych nieufnych,
  • ograniczenie możliwości klikania linków i otwierania kodów QR w interfejsach AI,
  • szkolenia uświadamiające pracownikom, że interfejs asystenta nie gwarantuje bezpieczeństwa treści,
  • monitorowanie ruchu sieciowego generowanego przez aplikacje AI,
  • testowanie systemów pod kątem indirect prompt injection i wycieków metadanych.

Użytkownicy końcowi również powinni zachować ostrożność. Nie należy automatycznie ufać alertom, prośbom o logowanie ani pilnym komunikatom prezentowanym przez asystenta. W przypadku wątpliwości należy samodzielnie przejść do usługi oficjalnym kanałem, zamiast korzystać z linków widocznych w odpowiedzi AI.

Podsumowanie

ChatGPhish pokazuje, że bezpieczeństwo aplikacji AI zależy nie tylko od odporności modelu na manipulację, ale również od tego, jak odpowiedź jest renderowana i odbierana przez użytkownika. Gdy nieufna treść zostaje przedstawiona jako część wiarygodnego interfejsu, powstaje nowa i bardzo skuteczna powierzchnia phishingowa.

Dla dostawców narzędzi AI i zespołów bezpieczeństwa to wyraźny sygnał, że odpowiedzi generowane na podstawie zewnętrznych materiałów powinny być traktowane jak potencjalnie skażone dane. Bez odpowiednich mechanizmów ochronnych interfejs asystenta może stać się nie tylko pomocą produktywności, ale także kanałem ataku.

Źródła

  • The Hacker News — ChatGPhish Vulnerability Turns ChatGPT Web Summaries Into a Phishing Surface — https://thehackernews.com/2026/05/chatgphish-vulnerability-turns-chatgpt.html
  • Permiso Security — ChatGPhish — https://permiso.io/

Krytyczna luka RCE w Flowise zwiększa ryzyko dla środowisk self-hosted po publikacji kodu exploitacji

Cybersecurity news

Wprowadzenie do problemu / definicja

W świecie narzędzi opartych na sztucznej inteligencji rośnie liczba incydentów wynikających nie tylko z klasycznych błędów programistycznych, ale również z niebezpiecznych założeń projektowych. Taki charakter ma podatność CVE-2026-40933 w platformie Flowise, popularnym rozwiązaniu open source do budowy przepływów LLM i agentów AI.

Problem dotyczy zdalnego wykonania kodu (RCE) i może zostać wykorzystany poprzez import spreparowanego pliku chatflow. Publiczne udostępnienie kodu proof-of-concept dodatkowo zwiększa ryzyko, ponieważ ułatwia odtworzenie scenariusza ataku także mniej zaawansowanym technicznie napastnikom.

W skrócie

Podatność oznaczona jako CVE-2026-40933 otrzymała ocenę krytyczną i dotyczy mechanizmu integracji MCP w Flowise. Luka pozwala na uruchomienie dowolnych poleceń systemowych na serwerze po zaimportowaniu złośliwego chatflow zawierającego odpowiednio przygotowaną konfigurację.

  • Zagrożone są przede wszystkim instancje self-hosted.
  • Atak może zostać uruchomiony poprzez import złośliwego pliku JSON.
  • Wektor wykorzystuje obsługę MCP w trybie stdio.
  • Publiczny kod exploitacji zwiększa prawdopodobieństwo masowych prób nadużyć.
  • Według dostępnych informacji Flowise Cloud nie jest objęte tym samym scenariuszem ataku.

Kontekst / historia

Luka została ujawniona w szerszym kontekście problemów bezpieczeństwa związanych z ekosystemami AI korzystającymi z protokołu MCP. Flowise znalazł się w grupie produktów narażonych na tę klasę błędów ze względu na sposób obsługi niestandardowych narzędzi oraz serializacji poleceń wykonywanych przez adapter stdio.

Rosnąca popularność Flowise jako platformy do wizualnego budowania przepływów dla modeli językowych sprawia, że produkt staje się atrakcyjnym celem dla cyberprzestępców. Dodatkowym czynnikiem ryzyka jest publiczna dostępność technicznych szczegółów oraz kodu PoC, co skraca czas potrzebny na przygotowanie skutecznej kampanii ofensywnej.

Analiza techniczna

Istota podatności sprowadza się do niebezpiecznej obsługi konfiguracji MCP w trybie stdio. W podatnych wersjach Flowise wcześniejszych niż 3.1.0 możliwe było dodanie komponentu MCP i zdefiniowanie polecenia systemowego, które następnie mogło zostać wykonane przez host obsługujący aplikację.

Scenariusz ataku wykorzystuje legalną funkcjonalność programu. Napastnik przygotowuje złośliwy chatflow z osadzonym niestandardowym narzędziem MCP, eksportuje go do formatu JSON i przekazuje ofierze. Po imporcie backend podejmuje próbę enumeracji dostępnych akcji narzędzia. Jeżeli wykorzystywany jest transport stdio, ten etap może doprowadzić do uruchomienia wcześniej zdefiniowanej komendy systemowej.

To oznacza, że wykonanie złośliwego kodu nie musi następować dopiero po ręcznym uruchomieniu przepływu. W praktyce zagrożenie może materializować się już podczas importu lub otwarcia konfiguracji, co znacząco zwiększa skuteczność ataku i utrudnia użytkownikowi rozpoznanie momentu kompromitacji.

Publicznie dostępny kod PoC pokazuje możliwość uzyskania powłoki systemowej. W środowiskach kontenerowych skutki mogą być szczególnie dotkliwe, zwłaszcza gdy proces Flowise działa z szerokimi uprawnieniami lub jako root wewnątrz kontenera.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest możliwość wykonania dowolnego kodu z uprawnieniami procesu Flowise. To z kolei może prowadzić do pełnego przejęcia aplikacji, odczytu sekretów, kradzieży tokenów API, dostępu do baz danych oraz wykorzystania integracji z usługami chmurowymi i systemami biznesowymi.

Skala ryzyka jest wysoka, ponieważ atak może zostać ukryty w pozornie legalnym pliku importu i wykorzystuje natywne funkcje aplikacji. Dla zespołów bezpieczeństwa oznacza to większą trudność w detekcji oraz konieczność analizy zdarzeń, które na pierwszy rzut oka mogą wyglądać jak normalna aktywność administracyjna.

  • możliwość przejęcia serwera aplikacyjnego,
  • ekspozycja kluczy API i danych uwierzytelniających,
  • dostęp do połączonych baz danych i usług zewnętrznych,
  • ryzyko ruchu bocznego w infrastrukturze organizacji,
  • zwiększone prawdopodobieństwo automatyzacji ataków po publikacji PoC.

W wielu środowiskach produkcyjnych Flowise pełni rolę warstwy orkiestracyjnej pomiędzy modelami AI, źródłami danych, API i zasobami chmurowymi. Z tego względu skuteczna eksploatacja może wywołać konsekwencje wykraczające daleko poza samą aplikację.

Rekomendacje

Organizacje korzystające z Flowise w modelu self-hosted powinny potraktować tę podatność jako priorytet krytyczny. Najważniejszym krokiem jest niezwłoczne usunięcie podatnych wersji oraz ograniczenie powierzchni ataku związanej z mechanizmem MCP.

  • zaktualizować Flowise do wersji 3.1.0 lub nowszej,
  • wyłączyć albo ograniczyć obsługę stdio MCP tam, gdzie nie jest niezbędna,
  • zablokować import chatflow z niezweryfikowanych źródeł,
  • ograniczyć liczbę użytkowników mogących tworzyć i edytować przepływy,
  • stosować zasadę najmniejszych uprawnień dla procesu Flowise,
  • unikać uruchamiania aplikacji z uprawnieniami root,
  • odseparować aplikację od wrażliwych zasobów poprzez segmentację sieci,
  • monitorować logi pod kątem nietypowych importów i uruchomień procesów potomnych,
  • przeprowadzić rotację sekretów i poświadczeń w razie podejrzenia kompromitacji,
  • wdrożyć dodatkowe zabezpieczenia kontenerowe, takie jak seccomp, AppArmor, SELinux oraz ograniczenia capabilities.

Z perspektywy detekcji warto korelować zdarzenia importu konfiguracji z pojawieniem się nowych procesów systemowych, nietypowymi połączeniami sieciowymi oraz zmianami w konfiguracji narzędzi MCP. W zespołach SOC zasadna jest również budowa reguł wykrywających procesy uruchamiane z kontekstu Flowise.

Podsumowanie

CVE-2026-40933 pokazuje, że w narzędziach AI szczególnie niebezpieczne mogą być błędy wynikające z połączenia legalnej funkcjonalności z niekontrolowanym wykonaniem komend systemowych. Publikacja kodu exploitacji znacząco zwiększa prawdopodobieństwo realnych ataków na instancje self-hosted.

Dla organizacji korzystających z Flowise oznacza to konieczność natychmiastowej weryfikacji wersji oprogramowania, ograniczenia funkcji MCP, przeglądu uprawnień oraz analizy ewentualnych śladów wcześniejszej kompromitacji. Im większy dostęp aplikacji do danych, modeli i usług produkcyjnych, tym poważniejsze mogą być skutki udanego ataku.

Źródła

  • SecurityWeek – Exploit Code Published for Critical Flowise RCE Vulnerability — https://www.securityweek.com/exploit-code-published-for-critical-flowise-rce-vulnerability/
  • NVD – CVE-2026-40933 — https://nvd.nist.gov/vuln/detail/CVE-2026-40933
  • Flowise – GitHub Repository — https://github.com/FlowiseAI/Flowise
  • Obsidian Security – Technical analysis of Flowise MCP exploitation — https://www.obsidiansecurity.com/

GREYVIBE: rosyjsko-powiązana grupa APT wykorzystuje AI do ataków na Ukrainę

Cybersecurity news

Wprowadzenie do problemu / definicja

GREYVIBE to nowo opisany klaster zagrożeń powiązany z rosyjskim ekosystemem operacji cybernetycznych, którego aktywność wymierzona jest przede wszystkim w Ukrainę oraz podmioty związane z administracją, wojskiem, biznesem i sektorem cywilnym. Na tle innych kampanii grupa wyróżnia się szerokim wykorzystaniem generatywnej sztucznej inteligencji i modeli językowych do przygotowywania infrastruktury, elementów malware, wabików oraz komponentów wykorzystywanych po uzyskaniu dostępu do systemów ofiar.

To istotna zmiana z perspektywy obrony, ponieważ AI pozwala napastnikom szybciej modyfikować narzędzia, tworzyć wiarygodniejsze treści socjotechniczne i sprawniej odbudowywać kampanie po wykryciu. W efekcie nawet aktor, który nie prezentuje najwyższego poziomu dojrzałości operacyjnej, może utrzymywać wysoką presję na cele strategiczne.

W skrócie

GREYVIBE prowadzi wielowektorowe operacje obejmujące spear phishing, fałszywe strony CAPTCHA, spreparowane serwisy podszywające się pod organizacje charytatywne oraz witryny socjotechniczne kierowane do użytkowników Windows i Androida. W kampaniach grupy pojawiają się własne narzędzia, w tym PhantomRelay, LegionRelay oraz mobilny spyware FallSpy.

  • Ataki są silnie ukierunkowane na pozyskiwanie informacji.
  • Grupa łączy techniki typowe dla APT i cyberprzestępczości.
  • W wielu etapach cyklu ataku wykorzystywana jest AI.
  • Kampanie obejmują zarówno urządzenia desktopowe, jak i mobilne.
  • Mimo licznych błędów operacyjnych zagrożenie pozostaje poważne.

Kontekst / historia

Badacze oceniają, że aktywność GREYVIBE trwa co najmniej od sierpnia 2025 roku. W tym czasie operatorzy rozwijali kilka odrębnych łańcuchów infekcji, które łączyły wspólne komponenty malware, podobna infrastruktura dowodzenia i kontroli oraz zbliżone techniki operacyjne. Dobór ofiar wskazuje, że nadrzędnym celem było pozyskiwanie danych wywiadowczych i budowanie dostępu do środowisk o znaczeniu strategicznym.

Analiza przypisuje działania grupy do rosyjskich interesów związanych z wojną przeciwko Ukrainie. Jednocześnie zespół odpowiedzialny za kampanie nie prezentuje dyscypliny typowej dla najbardziej zaawansowanych aktorów państwowych. Widoczne są ślady języka rosyjskiego, konfiguracje środowisk powiązane ze strefą UTC+3 oraz cechy kojarzone z wcześniejszymi klastrami cyberprzestępczymi. To wzmacnia hipotezę, że GREYVIBE funkcjonuje w modelu hybrydowym, łączącym interes państwowy z praktykami środowiska cybercrime.

Analiza techniczna

Najważniejszym wyróżnikiem GREYVIBE jest wykorzystanie AI na wielu etapach operacji. Obejmuje to generowanie obrazów używanych w kampaniach socjotechnicznych, tworzenie stron wabików, przygotowywanie skryptów obfuskacyjnych, budowę komponentów malware oraz wspieranie zaplecza serwerowego. Z punktu widzenia zespołów bezpieczeństwa oznacza to większą zmienność techniczną artefaktów i trudniejszą korelację incydentów na podstawie klasycznych wskaźników.

W kampanii PhantomMail atakujący wykorzystywali wiadomości spear phishingowe z odnośnikami do złośliwych archiwów przechowywanych w zewnętrznych usługach plikowych. Po uruchomieniu archiwum ofiara otrzymywała loader napisany w JavaScript lub spakowany przy użyciu PyInstaller. Mechanizm wyświetlał dokument-wabik albo komunikat błędu, a równolegle inicjował infekcję malware PhantomRelay.

PhantomClick bazował na technice przypominającej ClickFix. Ofiara trafiała na spreparowaną stronę CAPTCHA podszywającą się pod usługę konferencyjną lub platformę współpracy, po czym była nakłaniana do ręcznego uruchomienia poleceń pod pretekstem przejścia weryfikacji. W praktyce prowadziło to do zainstalowania PhantomRelay i uruchomienia kolejnych etapów kompromitacji.

Szczególnie nietypowy był zestaw działań określany jako PrincessClub. W tym scenariuszu grupa tworzyła fałszywe ukraińskie serwisy o charakterze randkowym lub erotycznym, które dostarczały FallSpy na Androida oraz warianty PhantomRelay lub LegionRelay na Windows. W późniejszych iteracjach witryny zyskały funkcję połączeń WebRTC, co mogło służyć do przechwytywania obrazu i dźwięku w czasie rzeczywistym. Taki model łączy dostarczanie malware z elementami zbierania informacji przypominającymi działania HUMINT.

Kampania DroneLink wykorzystywała strony podszywające się pod fundacje wspierające ukraińskie siły zbrojne i inicjatywy dronowe. W tych przypadkach ofiary otrzymywały komponenty powiązane z WireGuard oraz lekki RAT LegionRelay. Z kolei aktywność nazwana Nebo obejmowała próbki FallSpy oraz strony imitujące rosyjski wojskowy ekran logowania, prawdopodobnie w celu zwiększenia wiarygodności wabików wobec ukraińskiego personelu wojskowego.

PhantomRelay to modułowy RAT oparty na PowerShell, wykorzystujący komunikację WebSocket i pozwalający na wykonywanie poleceń systemowych oraz skryptów dostarczanych dynamicznie przez serwer C2. FallSpy działa jako spyware na Androidzie i umożliwia zbieranie kontaktów, historii połączeń, listy aplikacji, danych o urządzeniu, lokalizacji oraz plików multimedialnych. LegionRelay komunikuje się z infrastrukturą C2 przez REST API i wspiera działania po kompromitacji, takie jak enumeracja plików, eksfiltracja danych, wykonywanie zrzutów ekranu czy przygotowanie trwałego dostępu zdalnego.

W operacjach wykorzystywano również autorskie loadery i obfuskatory, w tym LOOKVALPS, LOOKVALJS, DAYLIGHT i TEASOUP. Częsta rotacja tych komponentów wskazuje na aktywne dostosowywanie narzędzi w celu utrudnienia detekcji. Jednocześnie właśnie tutaj ujawniły się błędy operatorów, takie jak wady projektowe LegionRelay, przesyłanie próbek testowych do publicznych serwisów analitycznych oraz pozostawianie artefaktów developerskich o nieformalnych nazwach. Te zaniedbania znacząco pomogły badaczom odtworzyć przebieg kampanii.

Konsekwencje / ryzyko

Ryzyko związane z GREYVIBE wynika z elastyczności kampanii i szerokiego zakresu celów. Atakujący dopasowują wabiki do kontekstu ofiary, korzystają z różnych kanałów wejścia i obejmują działaniami zarówno stacje robocze, jak i urządzenia mobilne. To zwiększa prawdopodobieństwo skutecznego przełamania zabezpieczeń i utrudnia budowanie jednolitego modelu obrony.

Dla organizacji największym zagrożeniem pozostaje cyberwywiad. Przejęcie komunikacji, dokumentów, danych lokalizacyjnych, zawartości urządzeń oraz informacji z aplikacji komunikacyjnych może prowadzić do ujawnienia informacji operacyjnych, identyfikacji personelu, mapowania relacji wewnętrznych oraz przygotowania kolejnych operacji, w tym działań dezinformacyjnych lub wspierających aktywność kinetyczną.

Dodatkowym problemem jest wykorzystanie AI do przyspieszania tworzenia nowych wariantów narzędzi. Nawet jeśli operatorzy popełniają błędy, zdolność do szybkiego generowania kodu, obrazów i infrastruktury skraca czas potrzebny do odtworzenia kampanii po wykryciu. Oznacza to, że mniej dojrzały aktor może utrzymywać skuteczność dzięki skali, szybkości adaptacji i niskim kosztom modyfikacji zaplecza.

Rekomendacje

Organizacje narażone na podobne działania powinny wdrożyć wielowarstwową ochronę obejmującą zarówno komponenty techniczne, jak i obszar świadomości użytkowników. Kluczowe jest ograniczanie możliwości uruchamiania ryzykownych skryptów, wzmacnianie kontroli ruchu wychodzącego oraz monitorowanie nietypowych zachowań na punktach końcowych.

  • Wzmocnić ochronę poczty i blokować archiwa oraz skrypty wysokiego ryzyka.
  • Monitorować uruchomienia PowerShell, Windows Script Host i ręcznie wklejane polecenia.
  • Inspekcjonować ruch do świeżo zarejestrowanych domen oraz nietypowych usług plikowych.
  • Uwzględnić w szkoleniach scenariusze ClickFix, fałszywe CAPTCHA, serwisy randkowe i spreparowane strony charytatywne.
  • Na urządzeniach mobilnych ograniczyć instalację aplikacji spoza oficjalnych źródeł i egzekwować polityki MDM.
  • W środowiskach podwyższonego ryzyka rozdzielać urządzenia służbowe i prywatne.
  • Zbierać szeroką telemetrię z punktów końcowych, aby wykrywać niestandardowe loadery i lekkie RAT-y.

Podsumowanie

GREYVIBE pokazuje, że skuteczne operacje cybernetyczne nie muszą być prowadzone wyłącznie przez aktorów o najwyższym poziomie zaawansowania. Dzięki systematycznemu wykorzystaniu AI grupa zwiększa tempo tworzenia narzędzi, poprawia wiarygodność socjotechniki i szybciej adaptuje kampanie do zmieniających się warunków.

Połączenie rosyjskiego kontekstu wywiadowczego, autorskiego malware, błędów operacyjnych i cech charakterystycznych dla cyberprzestępczości czyni z GREYVIBE zagrożenie trudne do jednoznacznej klasyfikacji, ale realnie niebezpieczne. Dla zespołów bezpieczeństwa oznacza to konieczność łączenia klasycznej ochrony technicznej z analizą behawioralną oraz regularnym przygotowywaniem użytkowników na coraz bardziej przekonujące techniki manipulacji.

Źródła

  • Security Affairs – Meet GREYVIBE, the Russian-Linked Hacking Group Using AI to Target Ukraine and Still Making Rookie Mistakes — https://securityaffairs.com/192877/apt/meet-greyvibe-the-russian-linked-hacking-group-using-ai-to-target-ukraine-and-still-making-rookie-mistakes.html
  • WithSecure Labs – GREYVIBE: A Russia-nexus group leveraging AI across state-aligned operations — https://labs.withsecure.com/publications/greyvibe

Fałszywe strony awarii ChatGPT wykorzystywane do dystrybucji malware przez legalne linki udostępniania

Cybersecurity news

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej wykorzystują zaufane platformy i legalne domeny do prowadzenia kampanii malware. W opisywanym przypadku nadużyto funkcji udostępniania treści w ChatGPT, aby wyświetlać fałszywe komunikaty o awarii usługi i nakłaniać użytkowników do pobrania rzekomej aplikacji desktopowej, która w rzeczywistości była nośnikiem zagrożenia.

Tego rodzaju atak jest szczególnie niebezpieczny, ponieważ ofiara widzi treść osadzoną w wiarygodnym środowisku i może błędnie uznać ją za oficjalny komunikat producenta. To przykład nowoczesnej socjotechniki, w której zaufanie do marki i domeny staje się elementem łańcucha infekcji.

W skrócie

Atakujący wykorzystali legalne linki współdzielenia ChatGPT do prezentowania spreparowanych ekranów sugerujących niedostępność wersji webowej. Następnie użytkownik był zachęcany do pobrania rzekomej aplikacji desktopowej, a kliknięcie prowadziło do zewnętrznej strony podszywającej się pod portal instalacyjny.

  • przynęta była hostowana w legalnej domenie usługi,
  • ruch do fałszywych stron był kierowany m.in. przez reklamy w wyszukiwarce,
  • ofiarom oferowano złośliwe pliki dla Windows i macOS,
  • kampania wykorzystywała cloaking i techniki unikania analizy.

Kontekst / historia

Nadużywanie rozpoznawalnych usług internetowych do hostowania lub pośredniczenia w atakach nie jest nowym zjawiskiem, ale rozwój narzędzi generatywnej AI znacząco zwiększył skuteczność takich operacji. Funkcje publikowania i udostępniania treści mogą być wykorzystywane do tworzenia materiałów, które wyglądają jak integralna część legalnej platformy.

Ta kampania wpisuje się w szerszy trend podszywania się pod popularne narzędzia AI. W poprzednich incydentach obserwowano już fałszywe instalatory, reklamy kierujące do spreparowanych stron oraz techniki ClickFix. Tym razem kluczowym elementem było użycie natywnego mechanizmu publikacji treści, co dodatkowo podniosło wiarygodność przynęty.

Analiza techniczna

Sercem kampanii było wykorzystanie funkcji share link do opublikowania zawartości, która przypominała ekran statusowy lub stronę awarii, a nie zwykłą rozmowę z modelem. Atakujący przygotowali interfejs imitujący oficjalny komunikat o przeciążeniu usługi i sugerowali przejście na aplikację desktopową.

Z perspektywy technicznej jest to istotna ewolucja klasycznego phishingu. Zamiast hostować stronę na własnej infrastrukturze, przestępcy oparli przynętę na zaufanej domenie. Taki zabieg utrudnia użytkownikowi ocenę ryzyka i może zmniejszać skuteczność prostych mechanizmów ochrony opartych wyłącznie na reputacji adresu URL.

Po kliknięciu przycisku pobrania ofiara była przekierowywana do zewnętrznej witryny podszywającej się pod legalny portal instalacyjny. Według analiz kampania stosowała cloaking, czyli różnicowanie treści zależnie od tego, kto odwiedza stronę. W efekcie narzędzia bezpieczeństwa mogły otrzymywać nieszkodliwy wariant, podczas gdy rzeczywisty użytkownik widział złośliwą wersję.

Próbki dla systemu Windows wykazywały zachowania typowe dla malware próbującego unikać analizy sandboxowej, w tym kontrole mające ustalić, czy kod działa na prawdziwym urządzeniu czy w maszynie wirtualnej. Choć nie wskazano jednoznacznie końcowego ładunku, tego typu kampanie są często wykorzystywane do dystrybucji infostealerów kradnących dane logowania, tokeny sesyjne, portfele kryptowalutowe i inne wrażliwe informacje.

Konsekwencje / ryzyko

Największe ryzyko dotyczy użytkowników, którzy samodzielnie pobierają narzędzia AI poza kontrolowanym procesem wdrożeniowym. Uruchomienie spreparowanego instalatora może prowadzić do przejęcia danych dostępowych, utraty sesji przeglądarkowych, kradzieży plików lokalnych lub uzyskania trwałego dostępu do stacji roboczej.

Dla organizacji problemem jest wysoka wiarygodność całego scenariusza. Legalna domena, znana marka i znajomy interfejs znacząco zwiększają prawdopodobieństwo sukcesu ataku. Użytkownik może nie zauważyć, że ufa nie oficjalnemu komunikatowi producenta, lecz treści opublikowanej przez nieznany podmiot w obrębie tej samej platformy.

Ryzyko nie kończy się na pojedynczym urządzeniu. Infostealer lub loader uruchomiony na komputerze pracownika może stać się punktem wejścia do dalszej kompromitacji środowiska firmowego, obejmującej skrzynki pocztowe, usługi SaaS, VPN, repozytoria kodu i zasoby chmurowe.

Rekomendacje

Organizacje powinny traktować linki współdzielenia z platform AI jako treści potencjalnie nieufne, nawet jeśli są hostowane w legalnej domenie. Ocena bezpieczeństwa nie może opierać się wyłącznie na reputacji adresu, ale również na analizie zachowania strony, przekierowań i pobieranych plików.

  • ograniczyć możliwość pobierania i uruchamiania nieautoryzowanych instalatorów,
  • wdrożyć listy dozwolonych aplikacji oraz egzekwować użycie podpisanych binariów,
  • monitorować pobrania plików wykonywalnych pochodzących z reklam i nietypowych ścieżek marketingowych,
  • wykrywać procesy sprawdzające obecność maszyny wirtualnej lub środowiska analitycznego,
  • blokować domeny podszywające się pod dostawców oprogramowania i mające niską reputację,
  • szkolić użytkowników, że komunikat wyświetlany w legalnej domenie nie zawsze jest autentyczny.

Z perspektywy SOC i threat huntingu warto zwrócić uwagę na nietypowe łańcuchy przekierowań, wzrost ruchu z reklam sponsorowanych do usług AI, pobrania plików DMG i EXE związanych z popularnymi narzędziami oraz artefakty charakterystyczne dla infostealerów. Istotne jest także monitorowanie tokenów sesyjnych i anomalii logowania po potencjalnej infekcji endpointu.

Podsumowanie

Opisana kampania pokazuje, że legalna domena i rozpoznawalna marka nie są już wystarczającym wyznacznikiem zaufania. Cyberprzestępcy wykorzystali funkcję udostępniania treści w ChatGPT do prezentowania fałszywego komunikatu o awarii, a następnie kierowali ofiary do pobrania złośliwego oprogramowania podszywającego się pod aplikację desktopową.

To przykład połączenia socjotechniki, nadużycia zaufanej platformy i technik unikania analizy. Dla firm i użytkowników oznacza to konieczność rozszerzenia modeli detekcji oraz edukacji bezpieczeństwa o scenariusze, w których sama obecność treści w legalnej usłudze nie gwarantuje jej autentyczności.

Źródła

  • https://www.bleepingcomputer.com/news/security/chatgpt-share-links-abused-to-host-fake-outage-pages-to-deliver-malware/
  • https://pushsecurity.com/blog/llmshare-chatgpt-share-links-malware/
  • https://www.virustotal.com/
  • https://app.any.run/

Złośliwy pakiet npm wykradał dane z katalogu Claude i ujawnił własny token GitHub

Cybersecurity news

Wprowadzenie do problemu / definicja

Ekosystem npm od lat pozostaje jednym z głównych celów ataków na łańcuch dostaw oprogramowania. Najnowszy incydent pokazuje jednak istotną zmianę: złośliwe pakiety zaczynają być projektowane nie tylko z myślą o klasycznych środowiskach deweloperskich, ale również o przestrzeniach roboczych używanych przez narzędzia AI wspierające programowanie.

W analizowanym przypadku pakiet podszywający się pod użyteczne narzędzie pomocnicze działał jak infostealer. Jego zadaniem było wyszukiwanie i kopiowanie plików z katalogu roboczego użytkownika, a następnie przesyłanie ich do repozytorium GitHub kontrolowanego przez operatora kampanii.

W skrócie

  • Zidentyfikowano złośliwy pakiet npm o nazwie mouse5212-super-formatter.
  • Malware próbował wykradać dane z katalogu /mnt/user-data, kojarzonego z przestrzenią roboczą używaną przez narzędzia oparte na Claude.
  • Do eksfiltracji wykorzystywano API GitHub oraz repozytorium tworzone lub kontrolowane przez atakującego.
  • Autor złośliwego pakietu popełnił błąd operacyjny i pozostawił w kodzie prywatny token GitHub, co ułatwiło analizę incydentu.
  • Przypadek potwierdza, że ataki na software supply chain coraz częściej obejmują również środowiska AI-assisted development.

Kontekst / historia

Ataki na npm zwykle opierają się na dwóch modelach. Pierwszy to publikacja pakietów podszywających się pod legalne biblioteki, narzędzia pomocnicze lub wewnętrzne komponenty używane przez zespoły developerskie. Drugi polega na przejęciu zaufanych procesów publikacji i dostarczeniu złośliwej wersji legalnej paczki do szerokiego grona odbiorców.

W ostatnich latach cyberprzestępcy wielokrotnie wykorzystywali ten wektor do kradzieży sekretów, tokenów dostępowych, poświadczeń do chmury, danych CI/CD oraz konfiguracji repozytoriów. Nowy incydent wpisuje się w ten trend, ale rozszerza go o nowy cel: dane znajdujące się w katalogach roboczych narzędzi AI, które mogą zawierać kod, dokumentację, wyniki analiz, artefakty sesji lub inne wrażliwe informacje.

To ważna zmiana z perspektywy obrońców. Środowiska AI dla programistów są często postrzegane jako warstwa wspierająca pracę dewelopera, a nie pełnoprawny element powierzchni ataku. Tymczasem właśnie tam mogą trafiać materiały o wysokiej wartości biznesowej i technicznej.

Analiza techniczna

Złośliwy pakiet został przedstawiony jako pozornie nieszkodliwe narzędzie synchronizacji lub formatowania. Po instalacji uruchamiał jednak kod odpowiedzialny za eksfiltrację danych. Mechanizm działania przypominał klasyczne infostealery stosowane w kampaniach wymierzonych w developerów.

Malware uwierzytelniał się wobec GitHub przy użyciu tokenu pobranego ze środowiska lub osadzonego bezpośrednio w próbce. Następnie sprawdzał istnienie wskazanego repozytorium, tworzył je w razie potrzeby i rozpoczynał przesyłanie plików za pośrednictwem GitHub Contents API.

Szczególnym celem był katalog /mnt/user-data. To właśnie ten obszar miał zawierać dane przetwarzane przez środowiska Claude, takie jak pliki wejściowe, wyniki pracy, artefakty sesji lub inne zasoby robocze. W praktyce oznacza to, że autor malware świadomie obrał za cel przestrzeń, w której użytkownik może przechowywać informacje wykraczające poza standardowe repozytorium projektu.

Istotnym elementem było również maskowanie działania. Pakiet generował pozorne komunikaty diagnostyczne związane z siecią, co mogło sprawiać wrażenie normalnej aktywności administracyjnej lub operacyjnej. Taka technika utrudnia szybkie rozpoznanie zagrożenia i może opóźnić reakcję użytkownika.

Najbardziej charakterystycznym elementem incydentu okazał się błąd sprawcy. Pozostawienie aktywnego tokenu GitHub w kodzie umożliwiło badaczom prześledzenie infrastruktury eksfiltracji oraz sposobu składowania skradzionych danych. Choć wskazuje to na niski poziom dojrzałości operacyjnej operatora, sam schemat ataku pozostaje niebezpieczny i łatwy do powtórzenia przez bardziej kompetentnych przeciwników.

Konsekwencje / ryzyko

Ryzyko związane z tym incydentem wykracza poza standardową kradzież pojedynczych sekretów zapisanych w zmiennych środowiskowych. Jeżeli w katalogu roboczym AI znajdowały się fragmenty kodu źródłowego, pliki konfiguracyjne, historię promptów, dane testowe, raporty bezpieczeństwa albo dokumenty projektowe, wszystkie te materiały mogły zostać przesłane do zewnętrznego repozytorium bez wiedzy użytkownika.

Dla organizacji oznacza to możliwość wycieku własności intelektualnej, danych operacyjnych oraz poświadczeń zapisanych w artefaktach roboczych. Dodatkowo incydent podważa założenie, że katalogi używane przez narzędzia AI mają wyłącznie charakter tymczasowy i nie przechowują zasobów o wysokiej wartości.

Niepokojące jest również wykorzystanie GitHub jako kanału eksfiltracji. W wielu organizacjach ruch do popularnych usług deweloperskich i zaufanych platform SaaS nie jest traktowany jako anomalia. Dzięki temu atakujący może ukryć złośliwą aktywność w legalnie wyglądającym ruchu sieciowym, co utrudnia detekcję na poziomie monitoringu i kontroli dostępu.

Rekomendacje

Organizacje korzystające z npm oraz narzędzi AI wspierających programowanie powinny potraktować ten incydent jako sygnał ostrzegawczy i rozszerzyć model ochrony łańcucha dostaw.

  • Ograniczyć wykonywanie skryptów instalacyjnych z niezaufanych pakietów oraz wdrożyć polityki dopuszczania zależności oparte na reputacji, pochodzeniu i kontroli integralności.
  • Monitorować stacje deweloperskie oraz środowiska build pod kątem nietypowego odczytu plików z katalogów roboczych narzędzi AI.
  • Minimalizować ilość wrażliwych danych przechowywanych w przestrzeniach roboczych agentów AI i traktować je jako obszary podwyższonego ryzyka.
  • Wdrożyć detekcję dla nietypowego użycia GitHub API, w tym tworzenia repozytoriów i masowych operacji przesyłania treści.
  • Regularnie rotować tokeny, rozdzielać konta publikacyjne od deweloperskich oraz stosować zasadę najmniejszych uprawnień.
  • Przeglądać historię instalacji pakietów, logi EDR, aktywność proxy oraz artefakty CI/CD pod kątem obecności pakietu mouse5212-super-formatter lub podobnych wzorców działania.
  • W przypadku podejrzenia uruchomienia paczki założyć kompromitację danych znajdujących się w katalogu roboczym i uruchomić standardowe procedury reagowania na incydenty.

Podsumowanie

Incydent z pakietem mouse5212-super-formatter pokazuje, że ataki na npm ewoluują wraz ze zmianą sposobu pracy programistów. Cyberprzestępcy przestają koncentrować się wyłącznie na klasycznych sekretach i coraz częściej interesują się danymi przetwarzanymi przez narzędzia AI.

Choć kampanię ułatwił błąd samego operatora malware, nie zmienia to znaczenia tego przypadku. Dla zespołów bezpieczeństwa jest to kolejny sygnał, że ochrona software supply chain musi obejmować nie tylko zależności, pipeline’y i sekrety, ale również środowiska AI oraz dane przetwarzane w ich katalogach roboczych.

Źródła

  1. Infosecurity Magazine — https://www.infosecurity-magazine.com/news/ai-npm-malware-leaks-github-token/
  2. PC Gamer — https://www.pcgamer.com/software/security/a-malware-dev-has-committed-a-magnificent-self-own-after-an-ai-coded-malicious-package-leaked-its-own-github-private-token/
  3. JFrog Security Research — https://research.jfrog.com/post/shai-hulud-here-we-go-again/
  4. Security Point Break — https://securitypointbreak.com/2026/05/27/malicious-npm-package-claude-ai-files/