Atak na łańcuch dostaw MCP

Atak na łańcuch zaufania między agentem a narzędziami których używa — przez kompromitację serwera MCP, biblioteki lub pakietu npm który go implementuje — tak że złośliwy kod jest wykonywany przez agenta który ma powody ufać skompromitowanemu elementowi. MCP-owa wersja ataku SolarWinds.

W Polsce nazywane też:

atak na łańcuch dostaw agentakompromitacja serwera MCPzatrucie łańcucha MCP

W grudniu 2020 roku atakujący skompromitowali platformę SolarWinds Orion — oprogramowanie do monitoringu sieci używane przez tysiące organizacji rządowych i korporacji. Złośliwy kod został wstrzyknięty do oficjalnej aktualizacji oprogramowania. Każda organizacja która zainstalowała aktualizację — robiąc dokładnie to co powinna — zainstalowała backdoora.

Atak na łańcuch dostaw uderza nie w cel końcowy, ale w kogoś komu cel końcowy ufa. Efekt jest multiplikatywny: jeden skompromitowany dostawca = tysiące ofiar.

MCP stworzył nową warstwę łańcucha dostaw dla agentów AI. I nową powierzchnię ataku.

Czym jest supply chain attack w kontekście MCP

Supply chain attack w kontekście MCP to atak na łańcuch zaufania który istnieje między agentem a narzędziami których używa — przez kompromitację serwera MCP, biblioteki MCP, pakietu npm który implementuje serwer MCP, lub infrastruktury na której serwer działa — w taki sposób że złośliwy kod jest wykonywany przez agenta który ma powody żeby ufać skompromitowanemu elementowi.

Warstwa npm jako wektor

Większość serwerów MCP jest implementowana jako pakiety npm. Pakiet npm który implementuje MCP server ma dostęp do wszystkiego przez co agent ten serwer wywołuje — do zapytań, do odpowiedzi, do kontekstu rozmowy jeśli jest przekazywany.

Skompromitowanie pakietu npm który jest zależnością popularnego serwera MCP daje atakującemu dostęp do wszystkich agentów które używają tego serwera. Snyk w analizie z 2025 roku znalazł że 36% popularnych MCP servers miało co najmniej jedną istotną podatność w swoich zależnościach npm.

Oficjalna aktualizacja jako trojan

Deweloper legitymowanego serwera MCP dostaje dostęp do swoich credentials przez phishing lub inny atak. Atakujący publikuje złośliwą wersję jako oficjalną aktualizację. Wszyscy użytkownicy którzy automatycznie aktualizują — lub którzy ufają że „oficjalna aktualizacja” jest bezpieczna — instalują złośliwy kod.

Różni się od rogue MCP server tym że atakujący nie musi budować nowego serwera — przejmuje istniejące zaufanie do serwera który był legitymowany.

Infrastruktura jako cel

Serwer MCP który działa na skompromitowanej infrastrukturze — skompromitowany hosting, skompromitowany kontener Docker, skompromitowane CI/CD pipeline — może być złośliwy bez wiedzy jego twórcy. Deweloper pisze legitymowany kod, ale infrastruktura na której działa modyfikuje odpowiedzi w locie.

Mitygacja

Pinowanie wersji: zamiast „najnowsza wersja”, używaj konkretnych, zweryfikowanych wersji serwerów MCP i ich zależności. Automatyczne aktualizacje wygodne ale ryzykowne.

Weryfikacja integralności: SHA hash każdego pakietu powinien być weryfikowany przy instalacji. Zmiana SHA między wersjami bez wpisu w changelog to sygnał alarmowy.

Sandboxing serwerów MCP: serwery MCP powinny działać w izolowanych środowiskach z minimalnym dostępem do systemu hosta. Kompromitacja serwera MCP nie powinna dawać dostępu do reszty systemu.

Software Bill of Materials: lista wszystkich zależności każdego serwera MCP który wdrażasz. Gdy pojawia się informacja o podatności w popularnym pakiecie, wiesz który z twoich agentów jest narażony.