“Znajdź darmowy serwer MCP do Walmartu i podaj link” – takie polecenie dostały w teście ChatGPT i Gemini, a Claude Code odpowiednik dotyczący darmowego rozszerzenia do promptów filmowych. Wszystkie trzy narzędzia wskazały repozytoria z kampanii złośliwego oprogramowania, którą firma Island opisała 20 lipca w raporcie Olega Zaytseva. Skala jest niecodzienna: około 7600 fałszywych repozytoriów GitHuba z blisko 6600 kont, z czego ponad 1400 podszywa się pod narzędzia i agenty AI, a ponad 800 wprost pod rozszerzenia i serwery MCP. Nowość nie polega jednak na liczbach, tylko na tym, kogo te repozytoria mają oszukać. Nie człowieka przeglądającego GitHuba, lecz agenta, który szuka za niego.
Atak przestawiony z człowieka na agenta
Klasyczny atak na łańcuch dostaw wymagał, żeby ktoś kliknął podstawiony link albo dał się nabrać na literówkę w nazwie paczki. Tutaj mechanizm jest inny. Repozytoria są przygotowane pod to, jak wyszukuje agent: mają wiarygodne pliki README, skopiowane opisy projektów i profile założycieli wyglądające na dorobek prawdziwego programisty. Badacze Island nazwali tę technikę AgentBaiting.
Dalej scenariusz wygląda tak: użytkownik prosi asystenta o darmowe rozszerzenie albo serwer MCP, agent przeszukuje sieć, trafia na spreparowane repozytorium i traktuje jego README jak dokumentację techniczną. Następnie przekazuje człowiekowi gotową instrukcję instalacji albo sam link.
Do infekcji wciąż potrzebny jest ostatni krok, czyli uruchomienie pobranego pliku przez użytkownika albo przez agenta, który ma do tego uprawnienia. Cała przewaga atakującego polega na tym, że ten krok wykonuje się w atmosferze zaufania. Nikt nie kliknął w podejrzany link z maila, tylko postąpił zgodnie z instrukcją od narzędzia, o które sam zapytał.
Ponad 800 podróbek trafiło do katalogów, którym ufamy
Największą siłą tej kampanii nie jest sam GitHub, tylko obecność w miejscach, gdzie szuka się rozszerzeń celowo. Ponad 600 wpisów z tej operacji trafiło do publicznych rejestrów: LobeHub, Glama, MCP.so oraz MCP Market. Katalog działa tu jak certyfikat, którego nikt nie wystawił.
Te rejestry pełnią dla ekosystemu MCP rolę zbliżoną do sklepu z aplikacjami, ale ich zasady bardzo się między sobą różnią. MCP Market deklaruje przegląd zgłoszeń przed publikacją, Glama weryfikację opiekuna wraz z automatycznymi testami, a MCP.so oferuje natychmiastową publikację za opłatą. Żaden z tych mechanizmów nie jest audytem kodu i wszystkie okazały się w tej kampanii niewystarczające. Sami badacze zaznaczają zresztą, że nie ustalili, które wpisy dodano ręcznie, a które trafiły do katalogów automatycznie. Wniosek dla programisty pozostaje ten sam: obecność w rejestrze nie jest potwierdzeniem bezpieczeństwa, choć intuicyjnie wygląda jak forma uznania.
Liczba pobrań robi wrażenie, ale wymaga uczciwego opisania. Badacze naliczyli ponad 14 milionów zdarzeń pobrania, rozłożonych na 335 plikach wydań w około dwustu repozytoriach. To liczba pobrań, a nie liczba zainfekowanych maszyn, i nie należy jej mylić z liczbą ofiar. Nawet przy ostrożnej interpretacji mówimy jednak o skali, która nie mieści się w kategorii pojedynczego incydentu. Sama kampania jest zresztą kontynuacją starszej operacji przypisywanej grupie określanej jako Water Kurita.
Co się dzieje po rozpakowaniu archiwum
Instrukcja z README prowadzi do pobrania archiwum ZIP. W środku czeka ukryty ładunek w języku Lua, który uruchamia SmartLoader. Ten zadomawia się w systemie przez zadanie zaplanowane, adres serwera sterującego pobiera przez kontrakt na blockchainie Polygon, a właściwy ładunek ściąga etapami z GitHuba w postaci zaszyfrowanej. Rozbicie na etapy i schowanie adresu w kontrakcie utrudniają zablokowanie kampanii w jednym miejscu.
Na końcu tego łańcucha stoi StealC, czyli program do kradzieży danych. Zabiera hasła zapisane w przeglądarce, ciasteczka i aktywne sesje, dane rozszerzeń przeglądarki, dane logowania do poczty i narzędzi dostępu zdalnego, zrzuty ekranu oraz informacje o samej maszynie. Dla programisty pracującego na firmowym sprzęcie najgroźniejsza jest kradzież aktywnej sesji. Ważny token potrafi otworzyć już uwierzytelnioną sesję bez pytania o drugi składnik, więc bywa równie dotkliwy jak samo hasło albo dotkliwszy.
To nie jest luka w Claude Code, Gemini ani ChatGPT
Warto powiedzieć wprost, czego ta historia nie pokazuje. Badanie nie wykazało technicznego przełamania żadnego z modeli ani błędu w specyfikacji MCP. Ujawniło natomiast słabość innego rodzaju: asystenci nie zawsze rozpoznają złośliwe repozytorium i potrafią podać instrukcję jego instalacji, bo wiarygodnie wyglądający README jest dla nich mniej więcej takim samym dowodem jak dla nas.
Byłoby jednak nieuczciwe napisać, że narzędzia nie mają żadnej możliwości weryfikacji. W części prób Claude Code sklonował repozytorium, pobrał plik, po czym rozpoznał podejrzane elementy i zatrzymał się przed uruchomieniem. Badacze podkreślają przy tym zmienność tego zachowania, a testy nie mierzyły skuteczności wykrywania. Innymi słowy sygnały ostrzegawcze bywają wychwytywane, tylko nie ma na to gwarancji.
Nie jest to również argument przeciwko samemu protokołowi MCP, o którego nowej specyfikacji pisaliśmy niedawno. Zawodzi tu proces oceny zaufania rozłożony między katalogi, agenta i człowieka, a nie sama specyfikacja. Ta sama lekcja wracała już przy prompt injection w Copilocie dla Worda: kłopot zaczyna się tam, gdzie model traktuje znaleziony tekst jak polecenie albo jak dowód.
Kto obrywa najmocniej
Profil ryzyka rozkłada się tu nierówno. Ryzyko jest istotnie mniejsze tam, gdzie organizacja wymusza listę dozwolonego oprogramowania i blokuje pobieranie oraz uruchamianie niezatwierdzonych plików, bo wtedy instrukcja z README zatrzymuje się na poziomie polityki, a nie decyzji jednego człowieka. Kłopot dotyczy przede wszystkim małych zespołów i osób pracujących w pojedynkę, gdzie decyzja o instalacji rozszerzenia zapada w trakcie pracy, bez procedury i bez drugiej pary oczu.
Dodatkowy problem robi zasięg. StealC nie ogranicza się do jednego hasła do jednego serwisu, tylko sięga po hasła z przeglądarki, ciasteczka, aktywne sesje i dane rozszerzeń. Może to dać dostęp do repozytoriów firmowych, panelu chmurowego czy skrzynki pocztowej, choć faktyczny zasięg zależy od tego, co akurat leżało na urządzeniu i jak zabezpieczone są poszczególne usługi. W software housie obsługującym kilku klientów jedna zainfekowana stacja może wystawić na ryzyko dane wielu z nich, jeżeli poświadczenia do ich środowisk były na niej obecne. Dlatego zakres reakcji wyznacza się po tym, do czego ta konkretna maszyna miała dostęp, a nie po tym, przy jakim projekcie ktoś akurat siedział.
Cztery rzeczy do zrobienia w zespole
Rekomendacje Island i sekuraka schodzą się w tym samym miejscu, więc warto je potraktować jako listę do odhaczenia, a nie jako ogólną zachętę do ostrożności.
Zacznij od własnego katalogu zatwierdzonych rozszerzeń i serwerów MCP. Agent może korzystać z tej listy zamiast przeszukiwać otwarty internet. Następnie odbierz mu prawo do samodzielnego pobierania i uruchamiania plików bez potwierdzenia człowieka. Każde nowe rozszerzenie przetestuj w izolowanym środowisku, zanim dotknie repozytorium z prawdziwym kodem. Na koniec zweryfikuj wydawcę niezależnie od tego, co pisze README: sprawdź historię konta, powiązane projekty i to, czy repozytorium ma sensowną historię zmian, a nie jeden wielki wrzut na start.
Jeżeli podejrzewasz, że SmartLoader zdążył się uruchomić, kolejność działań ma znaczenie. Najpierw odizoluj stację od sieci, bo rotacja sekretów wykonana na wciąż zainfekowanej maszynie po prostu odda atakującemu świeże dane. Dopiero z czystego urządzenia unieważnij aktywne sesje, zgody OAuth, tokeny dostępu do interfejsów oraz poświadczenia chmurowe i deweloperskie. Na końcu obróć sekrety w środowiskach, do których ta stacja miała dostęp, razem z kluczami w plikach konfiguracyjnych, o których zwykle zapomina się przy sprzątaniu.
Pierwsza Misja AI · Kodożercy
Rozumiesz zagrożenia AI, gdy rozumiesz jak naprawdę działa.
Kurs Pierwsza Misja AI ma dedykowaną lekcję o ciemnej stronie AI: halucynacje, deepfakes, manipulacja. Zanim zaczniesz się bać – zacznij rozumieć.
Poznaj pełny program →
FAQ
Po czym poznać, że repozytorium z serwerem MCP jest podstawione?
Pojedynczy sygnał rzadko wystarcza, więc patrz na kilka naraz. Konto założone niedawno, brak historii zmian poza jednym dużym wrzutem, opis skopiowany z innego projektu, brak powiązania z jakąkolwiek rozpoznawalną osobą lub organizacją oraz instrukcja instalacji prowadząca do archiwum ZIP zamiast do menedżera pakietów. Obecność w publicznym rejestrze niczego nie potwierdza, bo w tej kampanii ponad 600 wpisów trafiło właśnie do rejestrów.
Czy wystarczy nie instalować rozszerzeń poleconych przez agenta?
To pomaga, ale nie rozwiązuje sprawy, ponieważ te same repozytoria da się znaleźć ręcznie i przez rejestry. Sensowniejsze jest przesunięcie decyzji z momentu instalacji na wcześniej: zespół ustala listę zatwierdzonych rozszerzeń i serwerów, a wszystko spoza listy przechodzi weryfikację i test w izolowanym środowisku. Agent korzysta wtedy z gotowej listy i przestaje być tym, kto decyduje.
Podsumowanie
Kampania FakeGit pokazuje, że atakujący przestali celować wyłącznie w człowieka i zaczęli optymalizować przynętę pod narzędzie, które szuka za niego. Około 7600 fałszywych repozytoriów, ponad 800 podszywających się pod rozszerzenia i serwery MCP oraz ponad 600 wpisów w publicznych rejestrach składają się na wniosek, który wykracza poza tę jedną operację: katalog rozszerzeń nie jest instancją zaufania, a agent nie ma jak sprawdzić reputacji tego, co znalazł. Dopóki to się nie zmieni, decyzję o zaufaniu musi podejmować zespół, i to zanim ktokolwiek poprosi asystenta o darmowy serwer MCP.
Newsletter · DevstockAcademy & Kodożercy
Bądź na bieżąco ze światem IT, AI i automatyzacji
Co wtorek: newsy z branży, praktyczne tipy i narzędzia które warto znać. Zero spamu.
