Pisaliśmy już o serwerach MCP, których nikt nie sprawdził, i o większości publicznych serwerów, które wciąż pomijają OAuth. Oba teksty dotyczą serwerów, którym od początku nie należało ufać. Deadbugz, aktywna kampania ujawniona przez badaczy z Pillar Security i zarejestrowana 18 września 2026 w społecznościowym rejestrze incydentów MCP jako INC-136, to inny problem: serwer, który wyglądał dobrze, gdy go zatwierdzałeś, i później zmienił to, co robi.

Co znaleziono

Jedno konto na GitHubie złożyło 23 pull requesty w niepowiązanych repozytoriach narzędzi AI i deweloperskich, a każdy dodawał mały serwer MCP przedstawiany jako narzędzie zwiększające produktywność — formatowanie i streszczanie tekstu, nic, co wzbudziłoby podejrzenia w przeglądzie kodu. Żaden z pull requestów nie został scalony, zanim kampanię wykryto, i w momencie ujawnienia nie potwierdzono żadnego włamania; badacze traktują to jako zademonstrowaną technikę, a nie incydent z ofiarami.

Mechanizm: bramkowanie liczbą wywołań

Zachowanie serwera zależy od tego, ile razy klient go wywołał, a nie od tego, o co jest proszony — i właśnie dlatego przeszedł pobieżny przegląd i pierwszą sesję niezauważony.

01

Wywołanie pierwsze i drugie

Serwer zwraca dokładnie to, co obiecuje jego opis: sformatowany lub streszczony tekst. Recenzent, który go testuje, widzi małe, nudne, działające narzędzie.

02

Wywołanie trzecie

Serwer przepisuje zwracane metadane — opisy narzędzi, które model czyta jako instrukcje — na polecenia szukania kluczy SSH, danych uwierzytelniających AWS, historii powłoki i konfiguracji Kubernetes, i to po cichu.

03

Dlaczego przegląd oparty na sesji tego nie wykrywa

Większość ręcznych testów i jednorazowych procesów zatwierdzania kończy się po jednym lub dwóch wywołaniach. Ładunek jest zaplanowany tak, by pojawić się po momencie, w którym człowiek zwykle przestaje patrzeć.

Dlaczego to inne zagrożenie niż serwer złośliwy od pierwszego dnia

Opisy narzędzi w MCP nie są dokumentacją dla człowieka — to tekst, który podłączony model czyta i na którego podstawie może działać, i właśnie to w ogóle umożliwia prompt injection przez metadane narzędzi. Jednorazowe zatwierdzenie zakłada, że to, co zatwierdziłeś, pozostaje tym, co działa. Deadbugz pokazuje, że to założenie nie jest obecnie nigdzie w ekosystemie egzekwowane: nic w specyfikacji nie wymaga podpisanego manifestu narzędzi, a większość klientów nie prosi ponownie o zgodę, gdy definicje narzędzi wcześniej zatwierdzonego serwera się zmieniają.

Co z tym faktycznie zrobić

  • Twórz odcisk definicji narzędzi w momencie zatwierdzenia i porównuj go przy każdym ponownym połączeniu — zmiana to zdarzenie bezpieczeństwa, a nie rutynowa aktualizacja.
  • Traktuj każdą zmianę definicji na już zatwierdzonym serwerze jako wymagającą ponownej, wyraźnej zgody, a nie cichej automatycznej akceptacji.
  • Nie polegaj na pierwszej sesji przy sprawdzaniu serwera innej firmy. Jeśli Twój proces to „wypróbuj raz, potem ufaj”, to dokładnie tę lukę wykorzystuje ten atak.
  • Wybieraj serwery, których definicję kontrolujesz Ty lub Twoja platforma, zamiast pobieranych z otwartego rejestru lub z pull requesta, którego nie napisałeś.

W SuperCognit narzędzia agenta to punkty końcowe HTTP, które definiuje właściciel przestrzeni roboczej i które widzi w całości, a nie serwery innych firm pobierane z rejestru — na tej ścieżce nie ma pull requesta od obcej osoby. To omija tę konkretną kampanię, ale nie usuwa problemu u podstaw: każdy, kto podłącza Claude, Claude Code lub dowolnego innego klienta MCP do serwerów z otwartego ekosystemu, powinien traktować źródło serwera i każdą zmianę w tym, co ogłasza, jako rzeczy, które naprawdę warto sprawdzić.

Ten opis opiera się na publicznym ujawnieniu Pillar Security i wpisie w społecznościowej bazie incydentów MCP (INC-136); część szczegółów pochodzi z relacji wtórnych, a nie z oryginalnego opracowania, i w chwili pisania żadne z tych źródeł nie opublikowało informacji o potwierdzonej ofierze.