Deadbugz: serwer MCP, który staje się wrogi przy trzecim wywołaniu narzędzia, wypchnięty do 23 repozytoriów w 74 minuty

10 sierpnia 2026 r. jedno konto GitHub, zellkernel, otworzyło 23 pull requesty w ciągu 74 minut w niepowiązanych repozytoriach AI, MCP i narzędzi programistycznych, przy czym każdy dodawał serwer MCP o nazwie productivity-suite, który reklamował dwa zwykłe narzędzia, format_text i summarize. Według Pillar Security, która nazwała kampanię Deadbugz i opublikowała swoją analizę 12 sierpnia, serwer zwracał uczciwe wyniki przez pierwsze trzy wywołania, a następnie zmienił metadane przekazywane agentowi: opisy narzędzi i treść promptu zaczęły kierować model w stronę kluczy SSH, danych uwierzytelniających AWS, historii powłoki i konfiguracji Kubernetes oraz nakazywać mu ukrywanie tej aktywności przed użytkownikiem. Dziewiętnaście z 23 pull requestów zamknięto, cztery pozostawały otwarte, a żadnego nie scalono, gdy Pillar je analizowała. Nie potwierdzono żadnej ofiary. To jeden rekord, zgłoszony przez innych i przytoczony tutaj za nimi. Pozostałe udokumentowane incydenty z udziałem agentów, każdy z własnymi źródłami, poziomem istotności, oceną pewności i oznaczeniem sporu, znajdują się w archiwum incydentów AI — dzięki czemu kampanię w łańcuchu dostaw wymierzoną w narzędzia dla agentów można odczytać obok reszty tego, co faktycznie się wydarzyło.

Archiwum ocenia ten rekord jako charakteryzujący się wysoką istotnością i pewnością A — dobrze udokumentowany, ze zgodnymi źródłami pierwotnymi — jednocześnie odrębnie odnotowując brak potwierdzonych rzeczywistych szkód. Obie te rzeczy są prawdziwe naraz, a luka między nimi jest tym, czego dotyczy rekord: kampania, której projekt udokumentowano z niezwykłą szczegółowością, zanim doprowadziła do ofiary, którą ktokolwiek potrafi wskazać. Dwie istotne daty są oddalone o dwa dni. Pull requesty wysłano 10 sierpnia; Ariel Fogel z Pillar Security opublikował analizę 12 sierpnia, a wpis zawiera stałą adnotację, że będzie aktualizowany w miarę napływu zweryfikowanych informacji.

Trzy wywołania, następnie metadane ulegają zmianie.

Serwer MCP nie musi uruchamiać kodu na maszynie, aby zmienić działanie agenta. Definicje narzędzi są przekazywane modelowi jako kontekst w każdej sesji, co oznacza, że serwer, który je dostarcza, może zmienić instrukcje czytane przez agenta, pozostawiając nazwę narzędzia, jego repozytorium i manifest dokładnie w takim stanie, w jakim były. Deadbugz opiera się na tej asymetrii, a Pillar nazywa to runtime-gated MCP metadata poisoning.

Mechanizm jest na tyle prosty, że można go opisać w jednym zdaniu. Serwer utrzymuje w pamięci liczniktools/call żądań, osobny dla każdego klienta. Przez pierwsze trzy zachowuje się normalnie. Gdy licznik zostanie przekroczony, późniejsze odpowiedzi na tools/list i prompts/get wracają zmienione — inne opisy narzędzi, inna treść promptów — wskazując agentowi na klucze SSH, poświadczenia AWS, historię powłoki i konfigurację Kubernetes oraz polecając mu ukrycie tej aktywności przed użytkownikiem. Zatruty tekst promptu zawiera znacznik deadbugz oraz adres Bitcoin.

Brama jest również powodem, dla którego standardowe zabezpieczenia jej nie wykrywają. Ładunek jest obecny w źródle od pierwszego żądania; nic w kodzie ani w konfiguracji nie zmienia się w momencie przełączenia. Skanowanie statyczne, wpis w SBOM lub jednorazowe odczytanie manifestu narzędzia podczas instalacji widzą narzędzie do formatowania, ponieważ właśnie to zwraca narzędzie, dopóki licznik się nie przesunie. Pillar opisuje opóźnione przełączenie jako technikę unikania wykrycia stosowaną w badaniach i twierdzi, że jego badacze potwierdzili zarówno próg, jak i zmienione metadane, wysyłając żądania zawierające wyłącznie tekst do działającej zdalnej usługi i porównując odpowiedzi z publicznym źródłem.

Jeden szczegół sprawia, że pułapka jest szersza niż pojedyncza sesja. Serwer ogłasza tools.listChanged, zdolność MCP, która informuje klienta, że jego lista narzędzi została zmieniona. Klient, który honoruje ten sygnał, ponownie odczyta definicje w trakcie sesji i pobierze zatrutą wersję bez żadnej ingerencji operatora; klient, który buforuje definicje przy zatwierdzaniu, tego nie zrobi. To, jakie zachowanie ma dany agent, jest cechą klienta, a nie serwera, a opracowanie Pillar nie wymienia klientów z nazwy.

Dostawa: 23 pull requesty w ciągu 74 minut.

Dystrybucja nie polegała na pakiecie w rejestrze ani na zatrutej zależności ukrytej w pliku lockfile. Był to spam pull requestów wymierzony w projekty, które nie miały nic wspólnego z domniemaną funkcją serwera — czyli forma, jaką przybiera tania próba ataku w łańcuchu dostaw, gdy atakujący nie może uzyskać konta maintainera: zgłosić wystarczająco dużo zmian konfiguracji i czekać, aż któraś zostanie scalona lub zastosowana lokalnie.

Podział 23 przez Pillar jest trójdzielny. Siedemnaście dodaje zdalny punkt końcowy MCP, productivity-suite-mcp[.]onrender[.]com/mcp, hostowany na Render; cztery wywołują ukryty lokalny plik Python pod ~/.config/.cache/.sys/.deadbug-mcp.py; dwa to zgłoszenia do katalogów lub list, które opracowanie traktuje jako rozpoznanie lub wypełnienie, a nie jako dostarczenie. Podane okno czasowe to 9:52 PM do 11:07 PM UTC w dniu 10 sierpnia 2026 r. — w ujęciu ujawnienia 74 minuty, choć same dwa znaczniki czasu obejmują 75, i nic w zapisie nie zależy od tej minuty. Tylko jedno repozytorium docelowe jest wymienione z nazwy: getsentry/sentry-mcp, pull request #1239, podany jako przykład dostarczenia lokalnego artefaktu.

Konto stojące za tym było znaczące jak na swój wiek. W momencie zbierania danych przez Pillar zellkernel miał 50 publicznych repozytoriów, 20 z nich to forki, a 21 z tych 50 utworzono 10 sierpnia, tego samego dnia co kampanię. Profil był wzajemnie powiązany z kontem X @llmgod, które linkowało z powrotem do konta GitHub, co stanowi rodzaj wzajemnego linkowania wskazującego na tożsamość stworzoną w określonym celu, a nie przejętą.

Dziewiętnaście zamkniętych, cztery otwarte, zero scalonych to najczęściej powtarzana liczba w zapisie i zarazem ta, którą najczęściej odczytuje się jako zielone światło, choć nim nie jest do końca. Przycisk scalania na GitHubie nie jest rejestrem wykonania na hoście: maintainer może pobrać gałąź i ją uruchomić, ręcznie zastosować konfigurację albo zadanie CI może pobrać head PR-a, zanim ktokolwiek skomentuje. Cztery pull requesty, które zapisują konfigurację wywołującą ścieżkę do lokalnego skryptu, są tymi, w których ta luka ma największe znaczenie, ponieważ skrypt jest pobierany i uruchamiany całkowicie poza ewidencją scalania GitHub. Cloud Security Alliance Labs zwróciła uwagę na to samo w notatce z 2 września: liczby zamkniętych i niescalonych PR-ów nie dowodzą, że nic nie zostało uruchomione.

Co jest ustalone, a co nie

{{1}}Ustalono to na podstawie ujawnienia, w tym sensie, że Pillar relacjonuje to na podstawie artefaktów, które przeczytał, a w jednym przypadku usługi, którą odpytał: serwer i jego repozytorium źródłowe, dwa reklamowane narzędzia, licznik i próg trzech wywołań, cztery cele poświadczeń, liczby PR i ich status scalenia w momencie przeglądu oraz powiązanie między kontem GitHub a uchwytem X. Testowanie przeprowadzone przez Pillar na działającym punkcie końcowym jest najsilniejszym elementem na liście, ponieważ jest to reprodukcja, a nie odczyt kodu źródłowego.{{/1}}

Nie ustalono — i dokumentacja jest w tym ostrożna — czy była ofiara. Pole real_harm w archiwum ma wartość false, co jest stwierdzeniem dotyczącym dowodów, a nie zamiaru — nikt nie przedstawił hosta, logu ani skradzionego poświadczenia powiązanego z tą kampanią. Nie zidentyfikowano też osoby ani grupy stojącej za zellkernel i @llmgod; Pillar przypisuje operację tym kontom i na tym poprzestaje. Motyw finansowy opiera się na adresie Bitcoin osadzonym w ładunku, co jest wnioskiem ze wskaźnika, a nie ustaleniem dotyczącym sprawcy. A pytanie, na które obrońca najbardziej chce znać odpowiedź — czy kampania wciąż trwa — nie ma odpowiedzi w dokumentacji: wpis oznaczono jako taki, który będzie aktualizowany, a nie widać późniejszej wersji ani powiadomienia o usunięciu od GitHub lub Render.

Potwierdzenie jest słabsze, niż mogłaby sugerować ocena pewności, i warto to powiedzieć wprost. Dwie Cloud Security Alliance Labs — notatki badawcze, datowane na 30 sierpnia i 2 września 2026 r., powtarzają tę kampanię; późniejsza z nich wyraźnie stwierdza, że przypisuje Pillar odkrycie, szczegóły PR, zachowanie serwera i atrybucję konta, i nie opisuje żadnej własnej niezależnej weryfikacji. Na blogu Armor ukazał się post z 22 września 2026 r., który zawiera wskazówki dotyczące obrony i mówi, że Pillar rozebrał serwer; nie przedstawia żadnych własnych dowodów forensycznych. Nie nadano numeru CVE, a CSA twierdzi, że nie jest to podatność w specyfikacji MCP. Według stanu na 29 października 2026 r. wyszukiwania nie wykazują żadnego komunikatu doradczego od GitHub lub Render ani żadnej relacji w głównej prasie branżowej poświęconej bezpieczeństwu — żadnego materiału BleepingComputer, The Register, SecurityWeek czy Hackread — co jest nietypowe dla kampanii łańcucha dostaw o takim kształcie i samo w sobie jest częścią tego, co pokazuje zapis. "Źródła pierwotne są zgodne" oznacza tutaj jedno źródło pierwotne i zestaw dokumentów wtórnych, które się z niego wywodzą.

Dwie mniejsze niejasności warto zaznaczyć, zamiast je wygładzać. Wtórne podsumowania różnią się co do tego, czy trzecie wywołanie, czy czwarte jest pierwszym, które otrzymuje zatrute metadane, co wynika z opisu licznika jako przekraczającego próg przy trzecim żądaniu; zarówno rejestr, jak i ujawnienie podają trzy. Okno dostarczenia jest natomiast opisane jako 74 minuty dla znaczników czasu obejmujących 75.

Jednej weryfikacji nie udało się powtórzyć: 29 października 2026 r. konto GitHub zellkernel oraz repozytorium zellkernel/productivity-suite-mcp zwracają 404, a pojedynczy, wskazany z nazwy pull request, getsentry/sentry-mcp #1239, również nie daje się już odnaleźć — samo repozytorium przekierowuje teraz do getsentry/toolkit. Liczby PR-ów, status scalenia i zawartość repozytorium nie mogą zatem zostać dziś zweryfikowane bezpośrednio u źródła; pozostają migawką Pillar z połowy sierpnia.

Czego ujawnienie wymaga od obrońców

Odpowiedź, którą zaleca Pillar, dotyczy głównie traktowania metadanych jako powierzchni bezpieczeństwa, a nie jako jej opisu. W przypadku hostów konkretne zalecenia to blokować lub tropić productivity-suite-mcp[.]onrender[.]com/mcp, utrzymywać wcześniejszy punkt końcowy trycloudflare.com tej kampanii na listach blokad i poszukiwań, mimo że Pillar twierdzi, że nie jest obecnie aktywny, oraz nie uruchamiać deadbug-mcp.py — ukryta ścieżka pliku ~/.config/.cache/.sys/.deadbug-mcp.py jest artefaktem, którego należy szukać w katalogach domowych, repozytoriach i konfiguracjach klientów MCP.

Kolejność czynności śledczych ma większe znaczenie niż lista blokowanych. Jeśli host mógł nawiązać połączenie, Pillar zaleca zachowanie dzienników klienta MCP przed czyszczeniem czegokolwiek, a następnie przejrzenie odświeżeń definicji narzędzi i tego, co agent zrobił po trzecim wywołaniu; poświadczenia należy rotować tylko wtedy, gdy lokalne dowody potwierdzają ekspozycję, co jest przeciwieństwem odruchu rotowania wszystkiego przy podejrzeniu. Konfiguracja serwera pozwalała również na opcjonalną telemetrię do WEBHOOK_URL, beaconowanie przy połączeniu, pierwszym wywołaniu i zdarzeniu wyzwalającym — szczegół, który daje dochodzeniu trzecie miejsce do sprawdzenia poza dziennikami klienta i ruchem na punktach końcowych.

Dla osób budujących klienty MCP zalecenie ma charakter strukturalny i stanowi tę część zapisu, która zachowuje ważność najdłużej:

Obliczaj odciski (fingerprint) definicji narzędzi w momencie zatwierdzania i porównuj je przy każdym odświeżeniu, zamiast ufać nazwie i repozytorium serwera.

• Traktuj zmianę definicji na już zatwierdzonym serwerze jako zdarzenie bezpieczeństwa, które operator widzi i zatwierdza ponownie — a nie jako rutynowe zmiany w metadanych, które należy po cichu przełknąć.

• Wymuszaj operacje wrażliwe — dostęp do poświadczeń, wykonywanie kodu, pocztę wychodzącą, zapisy do repozytorium — poprzez politykę, a nie poprzez opisy dostarczane przez serwer.

To trzeci punkt sprawia, że Deadbugz jest czymś godnym odnotowania, a nie tylko ciekawostką. Każdy powyższy mechanizm kontrolny zakłada, że agenta można przekonać do różnych rzeczy za pomocą tekstu, który serwer dołącza do narzędzia, oraz że tekst ten może się zmienić po podjęciu decyzji o zaufaniu. Pillar umieszcza tę kampanię w szeregu obejmującym atak typu sleeper na MCP z 2025 r. przeprowadzony przez Invariant Labs, podrobiony pakiet postmark-mcp oraz udokumentowany przez Koi pakiet MCP zamieniony w broń za pomocą aktualizacji — wszystkie one stanowią precedensy dla tej techniki; Pillar przywołuje je w tym właśnie charakterze, a nie jako dowód dotyczący tego dostarczenia.

Dlaczego brama ma większe znaczenie niż liczba ofiar

Kampanię z 23 próbami dostarczenia, bez merge'a i bez potwierdzonego celu łatwo zaklasyfikować jako próbę i pójść dalej. Powód, dla którego należy ona do archiwum z wysoką ważnością, jest taki, że jej obejście nie zależy od powodzenia dostarczenia na dużą skalę. Zależy ona od właściwości, którą podziela dziś większość wdrożeń MCP: zatwierdzenie następuje jednorazowo, przy instalacji, a przyjmuje się, że zatwierdzona definicja to definicja, która będzie serwowana. Deadbugz utrzymuje to założenie w mocy przez trzy wywołania, a następnie je łamie.

Poprawka nie polega na łataniu konkretnego serwera i nie ma żadnego CVE, którego należałoby śledzić. Chodzi o to, że „zatwierdzony” musi stać się warunkiem ciągłym, popartym porównaniem — co jest zmianą w zachowaniu klientów i ich operatorów, a nie zmianą w tym, czego szuka skaner. Wciąż nie wiadomo, czy ktokolwiek faktycznie uruchomił ten serwer w sierpniu; zgodnie z obecnym stanem zapisów ustaleniem jest mechanizm.