Serwery MCP to nowa powierzchnia ataku

Model Context Protocol ma teraz bazę danych bezpieczeństwa. Zawiera 50 wpisów.¹

W ciągu 60 dni zgłoszono trzydzieści CVE. Spośród 2614 przebadanych implementacji MCP, 82% miało podatności operacji na plikach narażone na path traversal. Od 38% do 41% serwerów w ogóle nie posiadało uwierzytelniania.² Oficjalne narzędzie MCP Inspector — to, którego deweloperzy używają do debugowania serwerów MCP — miało podatność RCE. Powszechnie używany pakiet mcp-remote miał błąd OS command injection.¹

To nie jest teoretyczna powierzchnia ataku. Są to prawdziwe CVE w prawdziwych pakietach, które prawdziwi deweloperzy podłączają właśnie teraz do Claude Code, Codex CLI i Cursor. Niniejszy wpis rozszerza obszar bezpieczeństwa agentów o analizę zagrożeń na poziomie protokołu.

TL;DR

Serwery MCP są najszybciej rosnącą powierzchnią integracji w ekosystemie agentów. Są też najmniej audytowane. Baza podatności zawiera 50 wpisów: 13 krytycznych, 32 wysokich. Błędy walidacji danych wejściowych oraz prompt injection stanowią 30 z 50. Trzy podatności SSRF w trzech różnych serwerach MCP pojawiły się w jednym dniu w tym tygodniu.³ Wzorzec jest jasny: społeczność publikuje serwery MCP szybciej, niż je recenzuje.

Kluczowe wnioski

• Użytkownicy Claude Code: Każdy podłączany serwer MCP to granica zaufania, którą Pan/Pani rozszerza. Proszę teraz uruchomić claude mcp list i przeprowadzić audyt podłączonych serwerów. Jeśli korzysta Pan/Pani ze społecznościowych serwerów MCP zainstalowanych miesiące temu, warto sprawdzić, czy zostały od tamtej pory załatane.
• Twórcy powłok (harness): Hooki PreToolUse to ostatnia linia obrony, zanim wywołanie narzędzia MCP dotrze do nieaudytowanego serwera. Warto rozważyć hooki, które walidują dane wejściowe narzędzi MCP przed wykonaniem — zwłaszcza dla serwerów przyjmujących adresy URL, ścieżki plików lub polecenia powłoki.
• Autorzy serwerów MCP: Specyfikacja MCP mówi, że „POWINIEN być zawsze człowiek w pętli”. Należy to traktować jak MUSI. Proszę walidować wszystkie dane wejściowe. Nigdy nie należy przekazywać ciągów kontrolowanych przez użytkownika do poleceń powłoki poprzez interpolację stringów. Nigdy nie wolno ufać wartościom $ref w specyfikacjach OpenAPI bez walidacji URL.

Liczby

Projekt Vulnerable MCP utrzymuje bazę udokumentowanych problemów bezpieczeństwa MCP.¹ Aktualny stan:

Istotność: 13 krytycznych, 32 wysokie, 5 średnich.¹ Trzydziestu dwóch badaczy bezpieczeństwa wniosło swoje odkrycia. Dotknięte serwery obejmują własny serwer Git MCP firmy Anthropic, oficjalny MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes oraz ponad 20 serwerów społecznościowych.¹

Wynik badania jest najbardziej miażdżący: 82% z 2614 implementacji MCP miało podatności operacji na plikach narażone na path traversal.² Czterech na pięciu serwerów MCP pozwoli atakującemu odczytać pliki, do których nie powinien mieć dostępu.

Pięć wzorców ataku

60-dniowa fala CVE ujawniła pięć powtarzających się wzorców:²

1. Tool poisoning. Złośliwe instrukcje wbudowane w opisy narzędzi MCP. Agent odczytuje opis, ufa mu i wykonuje ukryte instrukcje przy użyciu własnych autoryzowanych narzędzi. Zatrute narzędzie nigdy się nie wykonuje — to legalne narzędzia agenta przeprowadzają atak. Opisaliśmy ten wzorzec w paradoksie deploy-and-defend: zaufanie jest przechodnie, audyt nie.

2. Prompt injection przez dane zewnętrzne. Serwery MCP, które pobierają treść z zagadnień GitHub, wiadomości Slack, maili czy stron internetowych, wprowadzają do kontekstu agenta tekst kontrolowany przez atakującego. Injection nie celuje w serwer MCP — celuje w agenta czytającego dane wyjściowe serwera. Powierzchnia ataku typu silent egress to przypadek ogólny; serwery MCP są najczęstszym wektorem.

3. Obejście zaufania po początkowej akceptacji. Claude Code prosi o zaakceptowanie serwera MCP przy pierwszym użyciu. Potem definicje narzędzi mogą zmieniać się między sesjami bez ponownego pytania we wszystkich przypadkach. Serwer, który był bezpieczny przy instalacji, może zachowywać się inaczej po aktualizacji. Luka w ponownej walidacji jest strukturalna: protokół nie wymaga kryptograficznego podpisywania opisów narzędzi.²

4. Kompromitacja łańcucha dostaw. Serwery MCP z backdoorami publikowane do rejestrów, w tym pakiety podszywające się pod legalne serwery. Ten sam wzorzec łańcucha dostaw udokumentowaliśmy w łańcuch dostaw to powierzchnia ataku, zastosowany do ekosystemu MCP.

5. Ekspozycja międzydzierżawna. Współdzielone środowiska hostingowe, w których wiele serwerów MCP może przechwytywać nawzajem swoje wywołania funkcji przed wykonaniem.⁴ Granice izolacji, które z zewnątrz wyglądają solidnie, załamują się, gdy wiele serwerów dzieli proces lub kontener.

Wzorzec SSRF

Trzy podatności SSRF w trzech różnych serwerach MCP pojawiły się w jednym skanowaniu w tym tygodniu:³

• n8n-mcp: Uwierzytelniony SSRF przez instance host injection
• mcp-from-openapi: SSRF przez wartości $ref w specyfikacjach OpenAPI. Złośliwa specyfikacja z wewnętrznymi URL powoduje, że serwer pobiera te zasoby podczas inicjalizacji
• stata-mcp: Niewystarczająca walidacja URL podanych przez użytkownika

SSRF w serwerach MCP jest szczególnie niebezpieczny, ponieważ serwer zazwyczaj ma dostęp do sieci, którego agent nie ma. Oto jak pojedyncza złośliwa specyfikacja OpenAPI staje się kradzieżą poświadczeń:

Krok 1. Atakujący publikuje wyglądający legalnie serwer MCP, który opakowuje zewnętrzne API. Serwer używa mcp-from-openapi do generowania narzędzi ze specyfikacji OpenAPI.

Krok 2. Specyfikacja OpenAPI zawiera $ref wskazujący na wewnętrzny adres:

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

Krok 3. Podczas initialize() serwer MCP rozwiązuje $ref przez pobranie URL. Serwer działa na Pana/Pani infrastrukturze: wewnątrz Pana/Pani VPC, na Pana/Pani laptopie, w Pana/Pani kontenerze CI. Żądanie trafia do endpointu metadanych AWS z zaufanego źródła.

Krok 4. Endpoint metadanych zwraca tymczasowe poświadczenia IAM: klucz dostępu, klucz tajny, token sesji.

Krok 5. Serwer ma teraz Pana/Pani poświadczenia chmury. Może je eksfiltrować w odpowiedziach narzędzi, logować do zewnętrznego endpointu lub używać bezpośrednio.

Agent nigdy nie zrobił niczego złośliwego. Użytkownik zaakceptował serwer MCP. Specyfikacja OpenAPI wyglądała normalnie. Rozwiązywanie $ref odbyło się na poziomie biblioteki, poniżej miejsca, które ktokolwiek przegląda. SSRF przekształcił pozycję sieciową serwera MCP w pozycję sieciową atakującego.

Microsoft załatał krytyczny Azure MCP SSRF (CVE-2026-26118) w marcu 2026. Ten sam wzorzec dotyczył Azure: podatność podniesienia uprawnień o wysokiej istotności, która mogła kraść tokeny uwierzytelniające i przyznawać nieautoryzowany dostęp do zasobów Azure.⁵

Co robić

Audytować podłączone serwery. Proszę uruchomić claude mcp list i przejrzeć każdy serwer. Warto porównać każdy z bazą Vulnerable MCP Project.¹ Należy usunąć serwery, z których się aktywnie nie korzysta.

Przypinać wersje serwerów. Jeśli instaluje Pan/Pani serwery MCP z npm lub pip, warto przypiąć wersję. Nie należy auto-aktualizować. Przed aktualizacją warto przejrzeć changelogi. Wzorzec obejścia zaufania oznacza, że aktualizacja może zmienić definicje narzędzi bez ponownej akceptacji.

Dodać hooki walidacji danych wejściowych. Hook PreToolUse na wywołaniach narzędzi MCP może walidować dane wejściowe, zanim dotrą do serwera:

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

Rozważyć izolację transportu. Wzorce obrony runtime dla agentów z narzędziami stosują się tu bezpośrednio: każdy serwer MCP to narzędzie, które agent wywołuje, a architektura obronna musi uwzględniać skompromitowane narzędzia. Serwery MCP HTTP działają we własnym procesie z jawnymi granicami sieciowymi. Serwery stdio dzielą kontekst procesu agenta. Żaden transport nie jest z natury bezpieczny. Większe znaczenie ma to, czy serwer ma dostęp do poświadczeń, sieci wewnętrznych czy wrażliwych ścieżek plików. Warto wybrać transport zapewniający granice izolacji wymagane przez model zagrożeń.

Obserwować bazę danych. Vulnerable MCP Project pod adresem vulnerablemcp.info to najbliższy odpowiednik trackera CVE dla ekosystemu MCP. Warto go sprawdzać przed instalacją nowych serwerów.

Ekosystem MCP rośnie szybko: ponad 3000 zaindeksowanych serwerów i 100 milionów miesięcznych pobrań.⁶ Postawa bezpieczeństwa z nim nie nadąża. Pięćdziesiąt podatności w bazie, która rok temu nie istniała. Problemem nie jest protokół. Są nim implementacje. Co więcej, jak udokumentowałem w Pana/Pani agent ma pośrednika, każdy pośrednik w łańcuchu narzędzi agenta to okazja do przechwycenia, której większość deweloperów nigdy nie audytuje.

Źródła

Często zadawane pytania

Czy serwery MCP dołączone do Claude Code są dotknięte?

Podatności dotyczą głównie serwerów MCP budowanych przez społeczność i strony trzecie, a nie podstawowej infrastruktury MCP Claude Code. Niemniej oficjalne narzędzie MCP Inspector miało podatność RCE, więc „oficjalne” nie oznacza „odporne”.

Czy powinienem/powinnam przestać używać serwerów MCP?

Nie. MCP to potężna warstwa integracji. Warto jednak traktować każdy serwer MCP jako granicę zaufania. Należy audytować podłączone serwery, przypinać wersje i dodawać hooki walidacji danych wejściowych dla serwerów przyjmujących URL, ścieżki plików lub polecenia powłoki.

Jak sprawdzić, czy moje serwery MCP są podatne?

Proszę uruchomić claude mcp list, aby zobaczyć podłączone serwery. Należy porównać każdy z bazą Vulnerable MCP Project. Warto też sprawdzić repozytorium GitHub serwera pod kątem ostatnich ostrzeżeń bezpieczeństwa.