Gdy patrzy się na pierwsze poważne podatności w serwerach MCP, pierwsza myśl jest zaskakująca: to są ataki, które znamy od lat. Path traversal, command injection, wstrzykiwanie kodu przez niesanitizowane dane wejściowe — te klasy błędów siedzą w OWASP Top 10 i CWE Top 25 od dawna. Nowe nie są podatności. Nowe jest to, gdzie się pojawiają i jak można je teraz wywołać.
Endor Labs przebadało 2614 implementacji MCP i wyniki są niepokojące w swojej klasyczności: 82% używa operacji na systemie plików podatnych na path traversal, 67% korzysta z wrażliwych API związanych z wstrzykiwaniem kodu, 34% jest narażone na command injection. To nie jest krajobraz nowych, egzotycznych zagrożeń. To jest krajobraz bardzo dobrze znanych błędów, które trafiły w nowe miejsce — i to miejsce ma jedną właściwość, której wcześniej nie miały: agenta AI jako pośrednika.
Trzy przypadki, jeden wzorzec
Oficjalna implementacja referencyjna Anthropic
W styczniu 2026 ujawniono trzy podatności w mcp-server-git — oficjalnym serwerze MCP do pracy z repozytoriami Git, stworzonym przez Anthropic jako implementacja referencyjna dla deweloperów. To ważny kontekst: materiały referencyjne są po to, żeby były kopiowane.
CVE-2025-68143 i CVE-2025-68145 to klasyczny path traversal. Narzędzie git_init tworzy repozytoria w dowolnych ścieżkach systemu plików, bo skonfigurowana granica --repository nigdy nie jest walidowana. Kod jest trywialny w swojej prostocie:
python
repo_path = Path(arguments["repo_path"])Żadnego sprawdzenia. Żadnego porównania z dozwolonym zakresem. Atakujący może wskazać dowolne miejsce w systemie plików. CVE-2025-68144 idzie dalej: argumenty przekazywane do poleceń Git CLI nie są sanitizowane, co umożliwia wstrzykiwanie argumentów bezpośrednio do wywołań systemowych.
Ale najciekawszy jest tutaj mechanizm ataku. Żeby wywołać te podatności, atakujący nie potrzebuje bezpośredniego dostępu do serwera MCP. Wystarczy, że agent przetworzy złośliwą treść — plik README w repozytorium, issue na GitHubie, stronę webową. Agent odczytuje zawartość, interpretuje ukrytą instrukcję jako część kontekstu zadania i sam wywołuje podatne narzędzie z payloadem atakującego. LLM staje się niezamierzonym pośrednikiem między złośliwą treścią a wrażliwą funkcją systemową.
600 000 pobrań i ukryty fallback
CVE-2025-53967 dotyczy Framelink Figma MCP Server — jednego z najpopularniejszych serwerów w całym ekosystemie, z ponad 10 000 gwiazdkami na GitHubie i 600 000 pobrań. Serwer łączy agenty AI z danymi projektowymi z Figma, tłumacząc odpowiedzi API na metadane użyteczne przy generowaniu kodu.
Podatność siedzi w mechanizmie fallback. Funkcja fetchWithRetry próbuje najpierw pobrać dane przez standardowe fetch API. Jeśli to zawiedzie — z powodu problemów sieciowych, błędów SSL albo ograniczeń proxy korporacyjnego — przechodzi na polecenie curl budowane przez konkatenację łańcuchów:
javascript
const curlCommand = `curl -s -S --fail-with-body -L ${curlHeaders.join(" ")} "${url}"`;Bez sanitizacji. Atakujący może wstrzyknąć dowolne polecenie przez parametr fileKey:
fileKey="$(id>/tmp/TEST)"Serwer uruchomi je z uprawnieniami procesu MCP.
Są dwa wektory. Bezpośredni: atakujący na tej samej sieci — publiczne Wi-Fi, sieć korporacyjna z przejętym urządzeniem — wysyła spreparowane żądanie. Pośredni przez DNS rebinding: ofiara odwiedza złośliwą stronę, która przekierowuje requesty do lokalnego serwera MCP na maszynie dewelopera. Do wykonania kodu nie jest potrzebna żadna interakcja z agentem.
Osobny problem: serwer domyślnie binduje się na 0.0.0.0 przez app.listen() bez podania nazwy hosta, co sprawia, że jest dostępny na wszystkich interfejsach sieciowych. Deweloperzy zakładają, że narzędzie działa tylko lokalnie — tymczasem domyślnie jest dostępne znacznie szerzej niż localhost.
Kiedy łańcuch zaufania sięga poza kod
CVE-2026-22785 i CVE-2026-23947 w Orval MCP pokazują trzecią warstwę problemu. Orval generuje klientów TypeScript z plików OpenAPI. Pole summary ze specyfikacji było wbudowywane do wygenerowanego kodu bez escapowania. Atakujący kontrolujący plik OpenAPI mógł wstrzyknąć kod bezpośrednio do generowanego klienta:
yaml
summary: Finds Pets.' + require('child_process').execSync("open -a Calculator").toString(),//Wygenerowany klient uruchamiał to przy przetworzeniu. To nie jest błąd w samym protokole MCP. To przypomnienie, że każdy serwer MCP przetwarza dane z zewnętrznych źródeł, których nie kontroluje — pliki projektowe, specyfikacje API, repozytoria, strony webowe. Łańcuch zaufania nie kończy się na implementacji narzędzia. Sięga przez każde źródło danych, które do niego trafia.
Dlaczego to nie jest tylko stary problem w nowym opakowaniu
Można powiedzieć, że te podatności to po prostu klasyczne błędy programistyczne, które pojawiają się wszędzie tam, gdzie jest nowy ekosystem z szybko rosnącą liczbą implementacji. I to byłoby częściowo prawdziwe. Ale MCP ma jedną właściwość, która zmienia charakter tych podatności.
W tradycyjnym modelu command injection atakujący musi dostarczyć złośliwy payload bezpośrednio do podatnego interfejsu — formularza, API, parametru. W modelu agentowym atakujący może dostarczyć payload przez treść, którą agent będzie przetwarzał: dokument, stronę, plik. Agent sam wywoła podatne narzędzie z odpowiednimi argumentami, bo tak zinterpretuje instrukcję zawartą w treści. Nie musi być tu żadnej interakcji z wejściem użytkownika. Nie musi być żadnego bezpośredniego dostępu do serwera.
To jest kluczowa zmiana. Powierzchnia ataku przesuwa się z interfejsu narzędzia na wszystko, co agent może przeczytać. Każdy dokument, każde repozytorium, każda strona internetowa, każda odpowiedź API staje się potencjalnym wektorem wywołania podatnej funkcji systemowej.
Endor Labs podsumowuje to wprost: LLM-y są pośrednikami i nie można zakładać, że przekazują do narzędzi MCP tylko "dobre" dane wejściowe. Model językowy przetwarza instrukcje. Nie umie niezawodnie odróżnić instrukcji od zaufanego operatora od instrukcji osadzonej w treści, którą właśnie przeczytał. To nie jest błąd do naprawienia w jednej aktualizacji — to jest właściwość systemu, z którą trzeba projektować architekturę.
Co to mówi o ekosystemie MCP
Pierwsze CVE w MCP nie są zaskoczeniem dla nikogo, kto śledził dynamikę wzrostu tego ekosystemu. Protokół zyskał masową adopcję zanim zdążyły pojawić się standardowe procesy security review, narzędzia do audytu i dobre praktyki dla implementatorów. Przy ponad tysiącu nowych serwerów tworzonych tygodniowo większość z nich powstawała bez żadnej weryfikacji bezpieczeństwa.
Podatności w oficjalnej implementacji referencyjnej Anthropic są tu szczególnie wymowne. Jeśli implementacja referencyjna zawiera path traversal i argument injection, to każdy deweloper, który ją skopiował zgodnie z przeznaczeniem, skopiował też podatności.
Wzorzec jest dobrze znany z historii innych ekosystemów. Npm przeszedł przez podobną fazę — szybki wzrost, słabe weryfikacje, podatności w powszechnie stosowanych pakietach, stopniowe dojrzewanie procesów bezpieczeństwa. MCP jest na początku tej krzywej, z tym że stawka jest wyższa: serwery MCP nie obsługują stron internetowych, ale infrastruktury deweloperskiej, danych operacyjnych i — przez agentów AI — coraz szerszego zakresu automatycznych działań w imieniu użytkownika.
Co z tego wynika
Najpraktyczniejszy wniosek dla teams korzystających z MCP brzmi tak: dane z LLM-ów i z serwerów MCP muszą być traktowane jak dane nieufane. Nie można zakładać, że model językowy będzie przekazywał do narzędzi tylko oczyszczone dane wejściowe — bo model nie jest komponentem bezpieczeństwa. Walidacja i sanitizacja muszą działać na granicy każdego narzędzia, niezależnie od tego, kto lub co je wywołuje.
Dla każdego serwera MCP wchodzącego do produkcji warto postawić kilka konkretnych pytań: czy ścieżki plików są walidowane względem dozwolonego zakresu? czy dane przekazywane do poleceń systemowych są sanitizowane? czy serwer nie binduje się domyślnie na wszystkich interfejsach sieciowych? jakie zewnętrzne źródła danych serwer przetwarza i jak traktuje ich zawartość?
To nie są pytania nowe. Są standardem AppSec od lat. Nowe jest tylko to, że ekosystem MCP zbudował sobie infrastrukturę, zanim ktokolwiek zdążył je zadać.
Źródła
Endor Labs — Classic Vulnerabilities Meet AI Infrastructure: Why MCP Needs AppSec, analiza CVE w ekosystemie MCP i dane z badania 2614 implementacji.
Imperva Threat Research — CVE-2025-53967, analiza podatności command injection w Framelink Figma MCP Server.
GitHub Security Advisories — CVE-2025-68143, CVE-2025-68144, CVE-2025-68145, podatności w mcp-server-gitAnthropic.
GitHub Security Advisories — CVE-2026-22785, CVE-2026-23947, podatności w Orval MCP.
