01Registry- und Supply-Chain-Risiken
MCP-Server werden überwiegend von unabhängigen Entwicklern gebaut und über inoffizielle Registries verteilt; ein offizielles Registry ist laut Wiz geplant, aber noch nicht verfügbar. Damit gelten die bekannten Muster von Paket-Ökosystemen: Typosquatting, Impersonation, Rug Pulls und Account-Übernahmen. Labels wie „official“ oder „verified“ bestätigen dabei weder die Identität des Entwicklers noch eine belegbare Verbindung zum genannten Produkt — Wiz berichtet zudem, dass rund 100 von etwa 3.500 gelisteten Servern eines untersuchten Registries auf nicht existierende Repositories verwiesen.
02Client-seitige Risiken und Auto-Run
Viele MCP-Clients führen Werkzeuge automatisch aus (Auto-Run); das vertraut Tool-Antworten implizit und vergrößert den Wirkungsradius eines kompromittierten Servers — laut Wiz ausdrücklich entgegen der MCP-Spezifikation. Hinzu kommen Tool-Namens-Konflikte, bei denen bewusst gleich benannte Werkzeuge legitime Funktionen überschreiben, das Kapern überlappender Slash-Kommandos wie /deploy oder /scan sowie indirekte Prompt Injection über untrusted Inhalte, etwa aus einer README oder Commit-Nachricht. Vorhandene Client-Guardrails sind laut Wiz uneinheitlich und wurden nicht mit Blick auf MCP-Sicherheit entwickelt.
03Belegte Vorfälle und CVEs
Dokumentiert sind unter anderem der Zugriff über den GitHub-MCP-Server auf private Repositories und deren Veröffentlichung sowie die Exfiltration von WhatsApp-Nachrichten durch einen bösartigen MCP-Server, der erst nach der zweiten Nutzung auf schädliches Verhalten umschaltete (beide von Invariant Labs beschrieben, im NSA-Leitfaden zitiert). Als Schwachstelle mit Kennung gilt CVE-2025-49596 im MCP Inspector: eine als kritisch eingestufte Remote Code Execution über ungeprüfte Eingaben, laut NSA behoben in Version 0.14.1. Wiz beschreibt zudem einen eigenen Proof of Concept (Gal Nagli), bei dem ein MCP-Server zum Parsen von GitHub-Dokumentation zu Remote Code Execution auf dem MCP-Host führte.
04Erkennung und Monitoring
Der NSA-Leitfaden empfiehlt, Netze regelmäßig auf offene, unautorisierte oder verwundbare MCP-Server zu scannen — auch weil diese ihre Ports dynamisch wechseln können, was differenzielle Scan-Berichte wertvoll macht; genannt werden Werkzeuge wie MCP Scanner, Ramparts, CyberMCP und Proximity. Alle Tool- und Modellaufrufe sollten mit Parametern und Identitäten protokolliert und in die vorhandene Überwachung (etwa ein SIEM) eingebunden werden, um auffällige Aufrufmuster zu erkennen. Ergänzend gehört ein formaler Prozess zur Verfolgung MCP-bezogener Schwachstellen über CVEs und Advisories samt einem gepflegten Inventar der eingesetzten Server dazu.
05MCP-Gateway und Allowlisting
Wiz empfiehlt, die MCP-Server-Nutzung über einen Proxy beziehungsweise ein MCP-Gateway zu zentralisieren, um einen einzelnen Kontrollpunkt für Audit-Logging, Monitoring, Guardrails und Governance zu schaffen. Ergänzend hilft Binary- und Server-Allowlisting im MCP-Host, das Ausführen unbekannter Server einzuschränken, sowie Sandboxing über Containerisierung, Egress-Kontrolle und Syscall-Filter — wobei Wiz betont, dass dies ein Weiterreichen des Angriffs an andere Server und Werkzeuge nicht verhindert. Die NSA nennt zusätzlich filternde Ausgangs-Proxys (etwa Squid oder tinyproxy) oder DLP-Lösungen sowie OS-Sandboxing mit seccomp, AppArmor, SELinux oder AppContainer.
06Was wir im Assessment prüfen
Wir inventarisieren die im Einsatz befindlichen MCP-Server und -Clients, prüfen Herkunft und Vertrauenssignale der genutzten Registries und bewerten Berechtigungen, Token-Scopes und Auto-Run-Verhalten gegen das Least-Privilege-Prinzip. Dazu gehören Netz-Scans auf offene oder unautorisierte MCP-Server, die Prüfung von Sandboxing, Gateway und Allowlisting sowie die Anbindung an Logging und SIEM. Auf dieser Basis liefern wir eine priorisierte Maßnahmenliste; vertiefend bieten wir Beratung, technische Assessments, Penetrationstests und Awareness-Formate wie Webinare an.
