Krytyczne luki w serwerach MCP: SSRF, RCE i ryzyko przejęć chmury w ekosystemie agentów AI (Microsoft, Anthropic)

Wprowadzenie do problemu / definicja luki

Model Context Protocol (MCP) to standard łączący modele językowe i agentów AI z narzędziami (np. repozytoriami Git, systemem plików, usługami chmurowymi czy konwerterami dokumentów). W praktyce MCP „wystawia” funkcje (tools), które agent może wywoływać w odpowiedzi na polecenia użytkownika… albo na polecenia przemycone w danych wejściowych (np. w README, stronie WWW, pliku).

Nowy problem nie polega wyłącznie na tym, że „gdzieś jest błąd”. Chodzi o to, że serwery MCP często działają jako uprzywilejowane pośredniki: mają dostęp do sieci, plików, tokenów, repozytoriów, a czasem wręcz do zasobów chmurowych. Jeśli da się nimi sterować (bez ograniczeń) albo jeśli agent da się nakłonić do uruchomienia sekwencji narzędzi — powstaje prosta ścieżka do SSRF, kradzieży sekretów i RCE.

---

W skrócie

• Badacze opisali poważne ryzyka w popularnych serwerach MCP: SSRF w Microsoft MarkItDown MCP oraz łańcuch prowadzący do RCE w oficjalnych serwerach MCP Anthropic (Git + Filesystem).
• W przypadku MarkItDown problemem jest możliwość pobierania dowolnych URI bez ograniczeń, co otwiera drogę do SSRF i np. odczytu metadanych instancji w chmurze.
• W przypadku Anthropic zidentyfikowano trzy luki (CVE-2025-68145 / -68143 / -68144), które można łączyć z innymi narzędziami MCP, by doprowadzić do wykonania kodu.
• Kluczowa lekcja: kompozycja narzędzi (tool chaining) + pośrednictwo agentów = ryzyko wykraczające poza „pojedynczą podatność” — to problem architektoniczny.

---

Kontekst / historia / powiązania

W artykule Dark Reading (20 stycznia 2026) podkreślono, że MCP powstał jako otwarty standard, a kwestie bezpieczeństwa w dużej mierze pozostawiono implementatorom. Efekt: część serwerów MCP „dowiozła funkcjonalność”, ale bez twardych barier bezpieczeństwa.

Microsoft równolegle publikuje materiały o zabezpieczaniu serwerów MCP (np. autentykacja/autoryzacja JWT, dobre praktyki dla wdrożeń oraz zarządzanie dostępem). To ważny sygnał: dostawcy widzą, że MCP szybko staje się infrastrukturą krytyczną, a nie tylko „wtyczką do LLM”.

---

Analiza techniczna / szczegóły luki

1) Microsoft MarkItDown MCP: SSRF przez „nieograniczone URI”

Z opisu wynika, że MarkItDown MCP przyjmuje od użytkownika/klienta URI wskazujące źródło pliku do konwersji i pobiera je bez mechanizmów ograniczających (brak sensownego allowlist/denylist, brak twardej walidacji docelowych adresów). To klasyczny wzorzec SSRF, tylko osadzony w nowym workflow: „agent → narzędzie MCP → sieć”.

Najbardziej niebezpieczny wariant to środowisko chmurowe: gdy serwer działa np. na instancji AWS EC2, możliwe jest odpytywanie usługi metadanych instancji (IMDS) i pozyskanie tymczasowych poświadczeń (access key/secret/session token) przypiętych do roli IAM. Dark Reading wskazuje też na różnicę odporności IMDSv2 vs IMDSv1.

Wniosek techniczny: w świecie MCP SSRF nie jest „tylko SSRF-em” — to często most do przejęcia chmury, bo serwer MCP bywa uruchamiany blisko sekretów, tokenów i metadanych infrastruktury.

2) Anthropic Git MCP + Filesystem MCP: łańcuch do RCE

Opisane błędy w oficjalnym Git MCP (mcp-server-git) obejmują m.in.:

• obejście walidacji ścieżek (CVE-2025-68145),
• możliwość inicjalizacji repozytorium w dowolnej lokalizacji (CVE-2025-68143),
• wstrzyknięcie argumentów/niebezpieczne obchodzenie się z parametrami w kontekście git_diff (CVE-2025-68144).

Kluczowe jest jednak to, jak dochodzi do RCE: podatności stają się groźne, gdy agent potrafi wykonać sekwencję działań przez różne narzędzia MCP (np. Git + Filesystem). Dark Reading opisuje scenariusz, w którym atakujący przemyca instrukcje poprzez indirect prompt injection (np. „złośliwe README”), a następnie agent wykonuje działania prowadzące do przygotowania repozytorium i uruchomienia poleceń (np. przez mechanizmy git związane z filtrami/atrybutami).

Wniosek techniczny: tu nie chodzi o „magiczne RCE w LLM”, tylko o bardzo klasyczny łańcuch: błąd kontroli ścieżek + możliwość zapisu plików + uruchomienie procesu (git) z podatnymi parametrami — tyle że zautomatyzowany przez agenta.

---

Praktyczne konsekwencje / ryzyko

Najbardziej realistyczne scenariusze nadużyć w organizacjach:

• Kradzież sekretów i eskalacja w chmurze: SSRF do IMDS / usług metadanych, odczyt tokenów, a potem przejęcie zasobów (storage, bazy, pipeline CI/CD).
• RCE na stacjach dev / runnerach CI: jeśli MCP serwery (Git/Filesystem) działają lokalnie lub w środowiskach build, skutkiem może być przejęcie repozytoriów, podmiana artefaktów, wstrzyknięcia do łańcucha dostaw.
• „Confused deputy” w architekturach pośredniczących: serwer MCP jako proxy do innych API może zostać użyty do uzyskania niezamierzonego dostępu, jeśli źle zaprojektowano autoryzację i zgody.
• Ataki przez dane, nie przez użytkownika: indirect prompt injection sprawia, że bodźcem jest treść (plik/WWW), a nie „zły użytkownik w czacie”. To zmienia monitoring i model zagrożeń.

---

Rekomendacje operacyjne / co zrobić teraz

Twarde ograniczenia dla SSRF (priorytet #1)

• Wprowadź allowlist schematów i hostów dla narzędzi pobierających zasoby (np. tylko https do zatwierdzonych domen/bucketów).
• Zablokuj dostęp sieciowy z procesu MCP do adresów link-local i usług metadanych (np. 169.254.169.254), a także do prywatnych zakresów, jeśli nie są potrzebne (egress filtering).
• W chmurze wymuś IMDSv2 tam, gdzie to możliwe (zmniejsza podatność na część klas SSRF).

Minimalizacja uprawnień i „blast radius”

• Uruchamiaj serwery MCP w izolacji (kontener, sandbox, osobna tożsamość) i dawaj im tylko minimalne uprawnienia (RBAC/least privilege).
• Rozdziel narzędzia „read” i „write”; operacje zapisu/niszczenia wymagaj jako jawnie zatwierdzane (human-in-the-loop dla krytycznych akcji).

Uwierzytelnianie i autoryzacja (bez tego MCP to „otwarta brama”)

• Zaimplementuj authn/authz dla MCP (np. JWT/OAuth) oraz kontroluj, kto może wywoływać które tool’e. Microsoft pokazuje podejście z JWT i praktycznymi wzorcami wdrożeniowymi dla serwerów MCP.
• Jeśli wystawiasz MCP przez warstwę zarządzania API, rozważ centralne egzekwowanie polityk dostępowych (klucze/subskrypcje, tokeny, walidacja) i spójny audyt wywołań.

Ochrona przed indirect prompt injection i „tool chaining”

• Traktuj treści zewnętrzne (WWW/pliki) jako dane nieufne i projektuj agenta tak, by oddzielać „instrukcje” od „kontekstu”.
• Dodaj reguły: agent nie może wykonywać operacji wysokiego ryzyka na podstawie niezweryfikowanej treści (np. z README). W praktyce: polityki wykonywania narzędzi, klasyfikacja ryzyka tool’i, oraz walidacje parametrów po stronie serwera MCP.

---

Różnice / porównania z innymi przypadkami

To nie jest „kolejna podatność w web appce”.
W klasycznym SSRF atakujący zwykle bije w endpoint aplikacji. W MCP często bije w narzędzie uruchamiane przez agenta, które działa z innym poziomem zaufania i uprawnień.

To nie jest też „tylko prompt injection”.
Prompt injection jest wyzwalaczem, ale realne szkody wynikają z tego, że agent ma dostęp do narzędzi o mocy porównywalnej z kontem uprzywilejowanym (chmura, system plików, repo). To przesuwa ciężar obrony na: tożsamość, granice sieciowe, walidację parametrów i polityki wykonywania narzędzi.

---

Podsumowanie / kluczowe wnioski

• MCP przyspiesza budowę agentów AI, ale jednocześnie tworzy nową, bardzo „twardą” powierzchnię ataku: SSRF → sekrety → przejęcie chmury oraz kompozycja narzędzi → RCE.
• Największe ryzyko wynika z braku ograniczeń na wejściu (URI/ścieżki/argumenty) i z faktu, że serwer MCP działa jako uprzywilejowany wykonawca.
• Skuteczna obrona to kombinacja: walidacji + izolacji + least privilege + kontroli tożsamości + polityk wykonywania narzędzi (a nie tylko „lepszego promptu”).

---

Źródła / bibliografia

1. Dark Reading — „Microsoft & Anthropic MCP Servers At Risk of RCE, Cloud Takeovers” (20.01.2026). (Dark Reading)
2. The Register — opis podatności i CVE w Anthropic Git MCP (20.01.2026). (The Register)
3. Microsoft Learn — „Foundry MCP Server best practices and security guidance” (aktualizacje i governance). (Microsoft Learn)
4. Microsoft TechCommunity — „It’s time to secure your MCP servers. Here’s how.” (JWT, podejście wdrożeniowe). (TECHCOMMUNITY.MICROSOFT.COM)
5. Model Context Protocol — „Security Best Practices” (ryzyka i mitigacje specyficzne dla MCP, m.in. confused deputy). (Model Context Protocol)