Cztery linijki dopisane do pliku .mcp.json wyglądają jak dołożenie czwartego narzędzia do trzech, które już tam stały. Dokładnie tak wyglądała propozycja zmiany złożona 10 sierpnia wieczorem w repozytoriach nuxt.com, sentry-mcp i todoist-mcp. Wpisywała serwer o nazwie productivity-suite, a razem z nim ukryty plik Pythona w katalogu domowym. Firma Pillar Security opisuje to jako kampanię Deadbugz. Naliczyła 23 takie zgłoszenia w ciągu 74 minut. Poszły także do vscode, ollamy, LangChaina i do oficjalnego repozytorium protokołu MCP. Sprawdziliśmy tę listę w publicznym API GitHuba i zgadza się co do sztuki. Przy naszym sprawdzeniu 12 sierpnia żadne zgłoszenie nie było scalone, tylko nie o scalenie tu chodzi. Złośliwy serwer MCP nie musi przyjść jako paczka z kodem, wystarczy mu wpis w konfiguracji.
Cztery linijki dopisane do pliku, który już tam był
Zgłoszenie zmian, po angielsku pull request, to propozycja poprawki wysłana do cudzego projektu. Opiekun projektu ją ogląda i albo przyjmuje, albo odrzuca. W tej kampanii przedmiotem propozycji nie był kod. W dwudziestu jeden zgłoszeniach był nim plik .mcp.json albo .cursor/mcp.json, w którym projekty trzymają listę serwerów MCP dostępnych dla agenta. Dwa pozostałe dotyczyły spisów gotowych serwerów.
Różnica między poszczególnymi zgłoszeniami jest tu ciekawsza niż to, co je łączy. W nuxt.com obok wpisu nuxt-hub pojawiła się czwarta pozycja. W sentry-mcp dopisano ją do dwóch plików naraz, zwykłego i tego dla Cursora, w obu obok istniejącego sentry-dev. Z kolei w todoist-mcp zmiana objęła przeformatowanie całego pliku. W podglądzie widać wtedy dziewięć dodanych linii, z czego nowe są cztery. Reszta to zmienione wcięcia.
W dużych projektach wyglądało to inaczej. W microsoft/vscode i ollama/ollama zgłoszenie zakłada plik .mcp.json od zera. Osiem linii, a w nich wyłącznie adres zdalnego serwera pod productivity-suite-mcp[.]onrender[.]com. Trudno o coś bardziej widocznego w przeglądzie zmian.
Pillar dzieli całą serię na trzy grupy. Siedemnaście zgłoszeń wpisuje zdalny serwer, cztery wskazują ukryty lokalny plik Pythona. Dwa ostatnie to wpisy do katalogów gotowych serwerów, więc do niczyjej konfiguracji nie wchodzą.
Serwer jest grzeczny przez dwa wywołania, groźny przy trzecim
Ta część pochodzi z analizy Pillara i sami jej nie odtwarzaliśmy, więc podajemy ją z atrybucją do autorów raportu.
Serwer productivity-suite deklaruje dwa niewinne narzędzia: formatowanie tekstu i streszczanie. Przez pierwsze dwa wywołania robi dokładnie to. Trzyma przy tym w pamięci licznik wywołań, osobny dla każdego podłączonego klienta. Po trzecim wywołaniu zmienia treść, którą odsyła agentowi w opisach narzędzi i w szablonach zapytań. Zamiast dokumentacji wraca instrukcja, żeby szukać kluczy SSH, poświadczeń AWS, historii poleceń powłoki i konfiguracji Kubernetesa. Przy okazji ma tego nie pokazywać operatorowi.
Autorzy raportu nazywają ten mechanizm zatruwaniem metadanych bramkowanym w czasie działania. Nazwa jest niezgrabna, a sedno proste. Opis narzędzia to nie etykieta, tylko treść, którą klient MCP podaje modelowi przy wyborze działania. Protokół pozwala serwerowi ogłosić, że lista narzędzi się zmieniła, i poprosić klienta o jej odświeżenie. Serwer korzysta z tej możliwości już po zaakceptowaniu instalacji.
Trzy wywołania to próg dobrany pod przeglądającego. Pillar nazywa go wprost techniką unikania badaczy. Krótka inspekcja, jedno zapytanie testowe albo automatyczny skaner dostaną wyłącznie nieszkodliwe metadane. Przy fałszywych serwerach MCP, które agenty same podsuwały problemem było to, że nikt tych repozytoriów nie sprawdzał. Tutaj sprawdzenie niczego nie daje, bo o tym, co zobaczy kontrolujący, decyduje serwer.
Trzy rzeczy do sprawdzenia w swoim repozytorium
Zanim przejdziemy do tego, jak kampania była przygotowana, kilka konkretów do zrobienia dziś. Zajmują kwadrans.
Po pierwsze, przeszukaj repozytoria pod kątem ciągu productivity-suite. Złośliwy serwer MCP nie ma numeru wersji ani autora, więc szuka się go po nazwie. Sprawdź .mcp.json, .cursor/mcp.json i konfiguracje klientów na maszynach zespołu. W tej kampanii ta sama zmiana trafiała do kilku plików naraz.
Po drugie, sprawdź katalog domowy pod ścieżką ~/.config/.cache/.sys/. Wszystkie trzy katalogi w tej ścieżce zaczynają się kropką i nie jest to przypadek. Takie katalogi nie pokazują się w domyślnym listowaniu.
Po trzecie pytanie na dłużej. Czy u was zmiana w konfiguracji agenta może wejść bez świadomej decyzji człowieka? Jeżeli macie automat, który wciąga ustawienia z gałęzi albo z propozycji zmian do środowiska testowego, to jest właśnie ta droga.
Raport dorzuca zalecenie dla twórców klientów MCP, warte zapamiętania także po stronie użytkownika. Serwer raz zaakceptowany może później zmienić opisy swoich narzędzi. Zdaniem autorów powinno to być zdarzenie widoczne dla operatora i wymagać zgody od nowa. Podpowiadają też prosty sposób na wykrycie: zapisać odcisk definicji narzędzi w chwili akceptacji i porównywać go później.
Kolejność zgłoszeń pokazuje, jak to przygotowano
Tu wchodzimy w ustalenia, których w raporcie nie ma. Wyciągnęliśmy z publicznego API GitHuba wszystkie 23 zgłoszenia razem ze znacznikami czasu i tytułami. Powtórzenie tego zajmuje jedno zapytanie do api.github.com/search/issues z warunkiem author:zellkernel.
Na pierwszy rzut oka tytuły tych zgłoszeń wyglądają identycznie. Identyczne nie są. Literalnie różnych wariantów jest osiem, a najczęstszy powtarza się trzynaście razy. Rozkładają się przy tym w czasie w sposób, który trudno uznać za przypadkowy.
Seria zaczyna się o 21:52 UTC od czterech zgłoszeń z przedrostkiem chore:, którym oznacza się rutynowe porządki w projekcie. Trzy noszą tytuł “chore: add local dev tooling configuration” i nie wspominają o żadnym serwerze. Czwarte, do sentry-mcp, nazwę serwera podaje. Te cztery to dokładnie te zgłoszenia, które wpisują ukryty lokalny skrypt Pythona zamiast adresu w sieci. Przedrostek chore: nie pojawia się w całej serii ani razu więcej. Najgroźniejszy wariant ładunku dostał najbardziej nudne opakowanie.
Potem, między 22:25 a 22:31, idzie pięć kolejnych zgłoszeń. Ich tytuły mówią już wprost o serwerze productivity-suite. Na końcu, między 22:59 a 23:07, leci czternaście zgłoszeń do największych celów. Są wśród nich oficjalne repozytorium MCP, claude-cookbooks, transformers, vscode, ollama, LangChain, AutoGPT, cline, autogen, litellm, OpenHands, llama.cpp, MetaGPT i crewAI.
Dane pokazują kolejność, nie zamiar, więc dalej idzie już nasze odczytanie. Zgłoszenia do dużych projektów widać od razu i zamyka się je w godziny, a trafiły na koniec serii. Cichy wariant poszedł pierwszy, do repozytoriów o wyraźnie mniejszym ruchu. Taki układ pasuje do kogoś, kto najpierw próbuje wejść niepostrzeżenie, a dopiero potem gra na liczbę celów.
Pierwsza Misja AI · Kodożercy
Używasz AI codziennie, ale czy robisz to dobrze?
Kurs Pierwsza Misja AI pokaże Ci techniki promptowania, które naprawdę działają. Praktyczne ćwiczenia z prawdziwym GPT-4, gamifikacja i certyfikat.
Sprawdź program kursu →
Czego w tej sprawie nie wiadomo
Warto postawić granicę, bo temat kusi do przesady.
Żadne z 23 zgłoszeń nie zostało scalone. Przy naszym sprawdzeniu 12 sierpnia dziewiętnaście było zamkniętych, cztery pozostawały otwarte, wszystkie w małych repozytoriach. Pillar formułuje to ostrożnie i pisze, że zgłoszenia nie zostały scalone mechanizmem scalania GitHuba. Ta ostrożność jest na miejscu i nie zamierzamy jej wyostrzać. Nie wiemy natomiast, czy ktokolwiek podłączył ten serwer u siebie ręcznie, ani czy komukolwiek coś wyciekło. Żadne źródło o tym nie mówi.
Nie wiemy też, kto stoi za kontem. Konto zellkernel założono 29 lipca, ma dziś 52 publiczne repozytoria i jednego obserwującego. W opóźnionym ładunku siedzi adres bitcoinowy. Raport zaznacza wyraźnie, że służy on do kojarzenia elementów kampanii. Dowodem na płatności ani na tożsamość nie jest, a powtarzamy to zastrzeżenie, bo w takich tekstach ginie najszybciej.
Zamknięcie zgłoszenia to również nie koniec sprawy. Odgałęzienia repozytoriów zostają. Dwa zgłoszenia w ogóle nie wchodziły do cudzej konfiguracji, tylko proponowały dopisanie serwera do spisów polecanych rozwiązań. Oba zamknięto, więc do żadnego katalogu nic nie trafiło. Pomysł wart jest jednak odnotowania, bo wpis w takim spisie działa jak rekomendacja i nie potrzebuje niczyjej zgody na instalację.
Konfiguracja to uprawnienia, nie kod
Zostaje pytanie, dlaczego akurat ta droga. Odpowiedź jest nudna i dlatego skuteczna.
Nowa zależność w projekcie zostawia ślady. Wchodzi do pliku blokady wersji, przechodzi przez skanery, budzi bota od aktualizacji, ma autora, licencję i historię wydań. Cała branża zbudowała wokół tego odruchy. Sporo z nich powstało po serii ataków na paczki, w tym po robaku, który podmieniał paczki npm z miliardami pobrań.
Wpis w .mcp.json nie ma nic z tego. To kilka linijek danych, bez wersji, bez sumy kontrolnej, bez podpisu. Przeglądający widzi poprawny plik i nazwę narzędzia do formatowania tekstu. Nie widzi natomiast tego, co ten wpis realnie robi. Przyznaje agentowi nowe źródło instrukcji, czynne wtedy, gdy agent pracuje najbardziej samodzielnie.
Dlatego wniosek z Deadbugz jest szerszy niż jedna nazwa do zablokowania. Zmiana w konfiguracji agenta zasługuje na taką samą uwagę jak zmiana uprawnień w systemie. Nie na taką, jaką dajemy poprawionej literówce w dokumentacji. Widać to zresztą w samych statusach. Wszystkie zgłoszenia do dużych projektów są już zamknięte, a te cztery, które przy naszym sprawdzeniu wciąż wisiały otwarte, poszły do małych repozytoriów. Ktoś cierpliwszy poprzestałby na takich celach.
Podsumowanie
Konto zellkernel złożyło 10 sierpnia w ciągu 74 minut 23 zgłoszenia zmian do cudzych projektów. Dwadzieścia jeden proponowało wpisanie do konfiguracji serwera MCP o nazwie productivity-suite, dwa dopisanie go do spisów gotowych serwerów. Według Pillar Security serwer przez dwa wywołania działa normalnie. Po trzecim podmienia opisy narzędzi na instrukcje szukania kluczy SSH i poświadczeń AWS oraz ukrywania własnej aktywności. Siedemnaście zgłoszeń wskazywało zdalny adres, cztery ukryty lokalny skrypt, dwa dopisywały serwer do katalogów. Sprawdziliśmy całą listę w publicznym API GitHuba 12 sierpnia. Żadne zgłoszenie nie było wtedy scalone, dziewiętnaście było zamkniętych, cztery pozostawały otwarte. Nasze własne ustalenie dotyczy kolejności. Cztery najwcześniejsze zgłoszenia, te z ukrytym skryptem, jako jedyne w serii miały tytuły z przedrostkiem od rutynowych porządków. Praktyczny wniosek nie zależy od losów tej jednej kampanii. Wpis w pliku konfiguracyjnym agenta nadaje uprawnienia i zasługuje na taki przegląd jak zmiana uprawnień.
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.
