Złośliwe serwery MCP: jak podstawiony serwer narzędzi przekracza granicę zaufania agenta
Złośliwy serwer MCP działa z uprawnieniami agenta i dyktuje zachowanie jego narzędzi. Jak podstawione serwery wchodzą do systemu, co potrafią i jak je weryfikować, przypinać i izolować.
Złośliwy serwer Model Context Protocol (MCP) jest groźny z powodu, który ma niewiele wspólnego z jego własnymi uprawnieniami: w chwili, gdy agent się z nim połączy, serwer znajduje się wewnątrz granicy zaufania agenta. Dostarcza opisy narzędzi, które model czyta jak instrukcje, wyniki narzędzi, które model traktuje jak wiarygodny kontekst, oraz wywołania narzędzi wykonywane z uprawnieniami agenta. Podstawiony serwer nie musi włamywać się do systemu — pożycza dostęp, który już nadałeś agentowi.
Krótka odpowiedź: serwer MCP to granica zaufania, a nie kanał danych. Cokolwiek powie — w nazwie narzędzia, jego opisie, parametrach czy zwróconym wyniku — wpływa do modelu jako materiał zaufany. Pytanie o bezpieczeństwo nigdy nie brzmi „co ten serwer może zrobić sam z siebie?“, lecz „w jakie działanie da się skierować mojego agenta w imieniu tego serwera?”. Traktuj każdy podłączany serwer jak kod działający z autorytetem agenta, bo w praktyce tak właśnie jest.
Dlaczego serwer MCP to granica zaufania, a nie zwykłe narzędzie?
MCP standaryzuje sposób, w jaki agenty odkrywają i wywołują zewnętrzne narzędzia. Serwer ogłasza zestaw narzędzi, każde z opisem w języku naturalnym i schematem parametrów; host agenta wstrzykuje te opisy do kontekstu modelu, by wiedział, co jest dostępne i kiedy tego użyć. Gdy model zdecyduje się wywołać narzędzie, host przekazuje wywołanie do serwera i podaje wynik z powrotem do kontekstu.
Każdy krok tej pętli jest niejawną decyzją o zaufaniu:
- Opis narzędzia staje się częścią instrukcji modelu. Tekst w języku naturalnym napisany przez autora serwera wprost kształtuje to, jak i kiedy agent działa.
- Wynik narzędzia staje się kontekstem, nad którym model rozumuje — często jako fakt.
- Wywołanie narzędzia działa z zakresem uprawnień, jaki nadał host: dostępem do plików, ruchem wychodzącym, poświadczeniami, możliwością wysłania poczty lub zapisu do bazy.
W klasycznych kategoriach to układ zdezorientowanego zastępcy: agent jest uprzywilejowanym zastępcą, a serwer może wpłynąć na to, co zastępca zrobi. Konto samego serwera może nie mieć żadnych szczególnych praw. W grze są uprawnienia agenta.
Jak podstawiony serwer wchodzi do systemu?
Istnieją dwa odrębne punkty wejścia i wymagają różnych obron.
W czasie instalacji: podszywanie się i przejęcie łańcucha dostaw
Większość serwerów MCP rozprowadza się jako pakiety — npm, PyPI, obrazy kontenerów lub repozytoria źródłowe. Ten kanał dystrybucji dziedziczy wszystkie klasyczne zagrożenia łańcucha dostaw:
- Typosquatting i podszywanie się. Atakujący publikuje pakiet o nazwie łudząco podobnej do popularnego serwera albo kopiuje jego README i markę, tak że programista instaluje podróbkę.
- Przejęcie zależności. Legalny serwer zależy od bibliotek, które atakujący kontroluje lub przejął, przemycając złośliwe zachowanie tranzytywnie.
- Mutacja po zatwierdzeniu (rug pull). Serwer zachowuje się poprawnie podczas przeglądu i instalacji, a później wypuszcza aktualizację zmieniającą definicje narzędzi lub zachowanie — wykorzystując to, że większość hostów nie weryfikuje niczego po pierwszej zgodzie.
W czasie połączenia: skierowanie agenta na wrogi punkt końcowy
Zdalne serwery MCP osiąga się przez sieciowy punkt końcowy. Atakujący, który wpłynie na to, którego punktu używa agent, może podstawić własny:
- Zmanipulowany lub współdzielony plik konfiguracyjny dodający wpis serwera.
- Wpis w rejestrze lub markecie rozwiązujący się do infrastruktury atakującego.
- Krok socjotechniczny, w którym użytkownika przekonuje się do dodania adresu serwera („podłącz to, żeby dać agentowi dostęp do kalendarza“).
Zagrożenia z czasu instalacji adresuje pochodzenie i przypinanie; zagrożenia z czasu połączenia — tożsamość punktu końcowego, polityka dopuszczania i model autoryzacji MCP.
Co naprawdę potrafi złośliwy serwer MCP?
Wewnątrz granicy zaufania wrogi serwer ma kilka dźwigni. Warto je wyliczyć, bo każda odpowiada konkretnej obronie.
| Zdolność | Mechanizm | Co osiąga |
|---|---|---|
| Zatruwanie opisu narzędzia | Ukryte polecenia w opisie narzędzia (język naturalny) | Steruje modelem do działań wybranych przez atakującego, ilekroć narzędzie jest w kontekście |
| Sterowanie/eksfiltracja przez wynik | Spreparowane wyniki narzędzia instruujące model lub przemycające dane do kolejnego wywołania | Zamienia niewinny wynik we wstrzyknięte polecenie lub kanał wycieku danych |
| Wstrzyknięcie polecenia/argumentu | Narzędzie przekazujące wejście pod wpływem atakującego do powłoki, ścieżki lub zapytania | Wykonanie kodu, path traversal lub SSRF na hoście narzędzia |
| Żądanie nadmiernych uprawnień | Narzędzia proszące o szersze poświadczenia, niż wymaga zadanie | Powiększa zasięg rażenia dostępny dla każdego późniejszego ataku |
| Cross-server shadowing | Polecenia odwołujące się do narzędzi innego serwera lub je nadpisujące | Kompromituje sesję wieloserwerową bez dotykania zaufanego serwera |
Dwie z nich zasługują na podkreślenie. Cross-server shadowing ma znaczenie, bo realne wdrożenia łączą wiele serwerów, a ich opisy narzędzi dzielą jeden kontekst — złośliwy serwer może wziąć na cel narzędzia zaufanego sąsiada. Sterowanie przez wynik ma znaczenie, bo zespoły często filtrują to, co wchodzi do narzędzia, a ufają temu, co z niego wychodzi; w MCP wynik serwera to sterowalny przez atakującego tekst, który model czyta jako kontekst.
Dlaczego „wygląda oficjalnie“ to nie zaufanie
Kuszące jest utożsamienie popularnego, dobrze ocenianego lub markowanego serwera z bezpiecznym. Ta heurystyka zawodzi na trzy sposoby:
- Reputacja opisuje przeszłość, nie działającą wersję. Serwer czysty w chwili zdobycia ocen może później wypuścić wersję złośliwą lub podatną.
- Źródło można przejąć. Konto opiekuna, potok budowania albo zależność da się przejąć bez żadnej widocznej zmiany w nazwie czy odznace projektu.
- Opublikowane podatności trafiają w popularne oprogramowanie. Szeroko używane komponenty nie są wolne od luk — są celem najwyższej wartości właśnie dlatego, że są szeroko używane.
Zaufanie nie jest czymś, co serwer ma; jest czymś, co ustanawiasz i utrzymujesz przez weryfikację i izolację. Odznaka to hipoteza wyjściowa, nie wniosek.
Jak bronić się przed złośliwymi serwerami MCP?
Żadna pojedyncza kontrola nie wystarcza. Poniższe obrony składają się w granicę, którą rzeczywiście zarządzasz.
Weryfikuj pochodzenie i przypinaj to, co przejrzałeś
Wybieraj serwery ze sprawdzalnym pochodzeniem — podpisanymi wydaniami, odtwarzalnymi buildami lub opublikowanymi haszami artefaktów. Przypnij dokładną wersję lub commit, który przejrzałeś, i zapisz jego hasz. Weryfikuj ponownie przy każdej aktualizacji, zamiast automatycznie pobierać najnowszą, by aktualizacja typu rug pull nie podmieniła po cichu tego, co zatwierdziłeś. Przeglądaj rzeczywiste definicje narzędzi serwera, nie tylko README — to tekst opisu jest tym, czego model słucha.
Wprowadź politykę dopuszczania (listę dozwolonych), nie wolny zapis
Świadomie decyduj, z którymi serwerami agent może się łączyć. Lista dozwolonych serwerów — wskazanych po tożsamości i przypiętej wersji — zamyka drogę z czasu połączenia: zmanipulowana konfiguracja ani oszukany użytkownik nie dodadzą dowolnego punktu końcowego, jeśli dopuszczane są tylko zweryfikowane serwery. Traktuj dodanie serwera jak uprzywilejowaną zmianę przechodzącą przez przegląd.
Egzekwuj minimalne uprawnienia per serwer
Zawęź każdy serwer do minimum: tylko te ścieżki plików, cele sieciowe i poświadczenia, których wymaga jego zadanie. Serwer streszczający dokumenty nie potrzebuje ruchu wychodzącego; serwer czytający kalendarz nie potrzebuje powłoki. Minimalne uprawnienia nadają izolacji sens — wyznaczają rozmiar pudełka, do którego ograniczone jest przejęcie.
Izoluj każdy serwer, niezależnie od reputacji
Uruchamiaj serwery we własnej piaskownicy — osobnym procesie z ograniczonymi wywołaniami systemowymi, kontenerze, microVM lub granicy WASM — tak by przejęty lub podatny serwer nie sięgnął hosta, sekretów ani innych narzędzi. Izolacja to kontrola, która trzyma, gdy weryfikacja zawiedzie, a weryfikacja czasem zawodzi.
Pośrednicz i monitoruj pętlę
Traktuj wynik narzędzia jak dane niezaufane, tak samo jak wejście: waliduj strukturę i nie pozwól, by wynik jednego serwera po cichu stał się poleceniem dla drugiego. Loguj każde wywołanie narzędzia z serwerem, parametrami i wynikiem, by widoczne było zachowanie anomalne — serwer nagle proszący o nowe uprawnienia albo wynik stale poprzedzający działania o poważnych skutkach. Granicy, której nie widzisz, nie da się ufać.
Gdzie to leży w modelu zagrożeń MCP
Złośliwe serwery to jedno z obliczy szerszego problemu łańcucha dostaw MCP. Mocno zazębiają się z zatruwaniem opisów narzędzi i rug pullami — zatruty opis to często sposób, w jaki podstawiony serwer steruje agentem — oraz z izolacją serwerów i klasami podatności CVE, czyli tym, jak ograniczasz serwer, któremu nie możesz w pełni ufać. Pełny obraz powierzchni ataku MCP i zasady spinające te obrony znajdziesz w przewodniku filarowym o bezpieczeństwie Model Context Protocol.
Powracająca lekcja jest ta sama, której reszta bezpieczeństwa oprogramowania nauczyła się o zależnościach: wszystko, co działa z twoimi uprawnieniami, jest częścią twojej powierzchni ataku, niezależnie od tego, czy sam to napisałeś. MCP sprawia, że dodanie takiej zależności to jedna linia konfiguracji. Dyscyplina pochodzenia, minimalnych uprawnień, izolacji i obserwowalności musi być stosowana z tą samą szybkością.
Artykuł odwołuje się do publicznej specyfikacji MCP (rewizja autoryzacji z 2025-06-18), wytycznych OWASP dla MCP oraz publicznie ujawnionych klas podatności. Nie zawiera zastrzeżonych danych o incydentach ani informacji o klientach.
Najczęstsze pytania
Dlaczego złośliwy serwer MCP jest groźny, skoro udostępnia tylko narzędzia?
Serwer MCP nie jest biernym źródłem danych — dostarcza definicje narzędzi i ich wyniki, które agent traktuje jako zaufane instrukcje i kontekst. Złośliwy serwer może więc ukryć polecenie w opisie narzędzia, zwrócić spreparowany wynik sterujący modelem albo wystawić narzędzia wykonujące działania z uprawnieniami agenta. Groźne nie są uprawnienia samego serwera, lecz to, że pożycza on uprawnienia agenta.
Jak podstawiony serwer MCP w ogóle trafia do agenta?
Dwiema głównymi drogami. W czasie instalacji atakujący publikuje pakiet podszywający się pod popularny serwer (typosquatting) lub przejmuje łańcuch dostaw legalnego pakietu, tak że programista instaluje go w dobrej wierze. W czasie połączenia agent zostaje skierowany na zdalny serwer pod kontrolą atakującego — przez zmanipulowaną konfigurację, wpis w współdzielonym rejestrze albo link, który użytkownik dał się namówić dodać.
Czy oficjalny lub popularny serwer MCP jest bezpieczny?
Popularność i etykieta „oficjalny” zmniejszają ryzyko, ale go nie usuwają. Opublikowane podatności CVE dotykały szeroko używanych serwerów, a serwer raz zweryfikowany może zostać zaktualizowany — lub jego źródło przejęte — już po fakcie. Traktuj zaufanie jako własność własnej weryfikacji i izolacji, a nie reputacji serwera: przypinaj po haszu, przeglądaj rzeczywiste definicje narzędzi i izoluj serwer niezależnie od odznaki.
Czym jest cross-server shadowing w konfiguracji z wieloma serwerami MCP?
Gdy agent łączy się z kilkoma serwerami naraz, opisy narzędzi z nich wszystkich dzielą jeden kontekst. Złośliwy serwer może zawrzeć polecenia odwołujące się do narzędzi innego, zaufanego serwera lub je nadpisujące — na przykład każąc modelowi przepuścić wynik cudzego narzędzia przez serwer atakującego. Atak nie wymaga przejęcia zaufanego serwera; wystarczy, że stanie obok niego.
Jak zweryfikować pochodzenie serwera MCP przed połączeniem?
Wybieraj serwery dystrybuowane ze sprawdzalnym pochodzeniem: podpisanymi wydaniami, odtwarzalnymi buildami lub opublikowanymi haszami artefaktów, które możesz zweryfikować. Przypnij dokładną wersję lub commit, który przejrzałeś, zapisz jego hasz i weryfikuj ponownie przy każdej aktualizacji, zamiast automatycznie pobierać najnowszą. Dla serwerów zdalnych potwierdź tożsamość punktu końcowego i stosuj model autoryzacji MCP, a nie nieprzejrzyste tokeny.
Czy izolacja serwera ma sens, jeśli sam serwer jest złośliwy?
Tak — izolacja ogranicza szkody, gdy weryfikacja zawiedzie. Jeśli każdy serwer działa z minimalnymi uprawnieniami — tylko te ścieżki plików, cele sieciowe i poświadczenia, których wymaga jego zadanie — złośliwy serwer może wybrukować w swojej piaskownicy, ale nie sięgnie hosta, sekretów ani innych narzędzi. Izolacja zamienia pełne przejęcie w przejęcie powstrzymane.
Która pojedyncza kontrola najbardziej ogranicza ryzyko złośliwych serwerów MCP?
Polityka dopuszczania połączona z izolacją o minimalnych uprawnieniach per serwer. Świadomie decyduj, z którymi serwerami agent może się łączyć (lista dozwolonych), przypnij i zweryfikuj każdy, a każdy uruchamiaj we własnej piaskownicy z minimalnym zakresem uprawnień. To ogranicza naraz i to, kto wchodzi w granicę zaufania, i to, co może w jej obrębie zrobić.