MCP-Server sind die neue Angriffsfläche

Das Model Context Protocol hat jetzt eine Sicherheitsdatenbank. Sie enthält 50 Einträge.¹

Dreißig CVEs wurden in 60 Tagen eingereicht. Unter 2.614 untersuchten MCP-Implementierungen hatten 82 % Schwachstellen bei Dateioperationen, die für Path Traversal anfällig waren. Zwischen 38 % und 41 % der Server verzichteten vollständig auf Authentifizierung.² Das offizielle MCP Inspector Tool – jenes Werkzeug, das Entwickler zum Debuggen von MCP-Servern nutzen – wies eine RCE-Schwachstelle auf. Das weit verbreitete mcp-remote-Paket hatte eine OS-Command-Injection-Lücke.¹

Dies ist keine theoretische Angriffsfläche. Es handelt sich um reale CVEs in realen Paketen, die reale Entwickler gerade jetzt mit Claude Code, Codex CLI und Cursor verbinden. Dieser Beitrag erweitert das Gebiet der Agenten-Sicherheit um eine Bedrohungsanalyse auf Protokollebene.

TL;DR

MCP-Server sind die am schnellsten wachsende Integrationsfläche im Agenten-Ökosystem. Sie sind zugleich die am wenigsten geprüfte. Die Schwachstellendatenbank enthält 50 Einträge: 13 kritisch, 32 hoch. Fehler bei der Eingabevalidierung und Prompt Injection machen 30 der 50 aus. Diese Woche kamen an einem einzigen Tag drei SSRF-Schwachstellen in drei verschiedenen MCP-Servern ans Licht.³ Das Muster ist eindeutig: Die Community veröffentlicht MCP-Server schneller, als sie sie prüft.

Wichtigste Erkenntnisse

• Claude Code-Benutzer: Jeder MCP-Server, den Sie anbinden, ist eine Vertrauensgrenze, die Sie erweitern. Führen Sie jetzt sofort claude mcp list aus und prüfen Sie, was Sie verbunden haben. Wenn Sie Community-MCP-Server betreiben, die Sie vor Monaten installiert haben, überprüfen Sie, ob diese seither gepatcht wurden.
• Harness-Entwickler: Ihre PreToolUse-Hooks sind Ihre letzte Verteidigungslinie, bevor ein MCP-Toolaufruf einen ungeprüften Server erreicht. Ziehen Sie Hooks in Betracht, die MCP-Tool-Eingaben vor der Ausführung validieren, insbesondere bei Servern, die URLs, Dateipfade oder Shell-Befehle entgegennehmen.
• MCP-Server-Autoren: Die MCP-Spezifikation besagt, es „SOLLTE stets ein Mensch in der Schleife sein”. Behandeln Sie das als MUSS. Validieren Sie alle Eingaben. Übergeben Sie nie benutzergesteuerte Zeichenketten per String-Interpolation an Shell-Befehle. Vertrauen Sie nie $ref-Werten in OpenAPI-Spezifikationen ohne URL-Validierung.

Die Zahlen

Das Vulnerable MCP Project pflegt eine Datenbank dokumentierter MCP-Sicherheitsprobleme.¹ Der aktuelle Stand:

Schweregrad: 13 kritisch, 32 hoch, 5 mittel.¹ Zweiunddreißig Sicherheitsforscher steuerten Funde bei. Zu den betroffenen Servern zählen Anthropics eigener Git-MCP-Server, der offizielle MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes und mehr als 20 von der Community entwickelte Server.¹

Der vernichtendste Befund der Studie: 82 % von 2.614 MCP-Implementierungen wiesen Schwachstellen bei Dateioperationen auf, die für Path Traversal anfällig waren.² Vier von fünf MCP-Servern lassen einen Angreifer Dateien lesen, auf die er keinen Zugriff haben sollte.

Fünf Angriffsmuster

Die CVE-Welle der vergangenen 60 Tage offenbarte fünf wiederkehrende Muster:²

1. Tool Poisoning. Schadhafte Anweisungen, die in den Beschreibungen von MCP-Tools eingebettet sind. Der Agent liest die Beschreibung, vertraut ihr und befolgt die versteckten Anweisungen mithilfe seiner eigenen autorisierten Werkzeuge. Das vergiftete Tool selbst kommt nie zur Ausführung – die legitimen Werkzeuge des Agenten führen den Angriff aus. Dieses Muster haben wir im Deploy-and-Defend-Paradox behandelt: Das Vertrauen ist transitiv, das Audit nicht.

2. Prompt Injection über externe Daten. MCP-Server, die Inhalte aus GitHub-Issues, Slack-Nachrichten, E-Mails oder Webseiten abrufen, bringen vom Angreifer kontrollierten Text in den Kontext des Agenten. Die Injection zielt nicht auf den MCP-Server – sie zielt auf den Agenten, der die Ausgabe des Servers liest. Die stille Egress-Angriffsfläche ist der allgemeine Fall; MCP-Server sind der häufigste Vektor.

3. Umgehung der Vertrauensprüfung nach anfänglicher Genehmigung. Claude Code bittet Sie beim ersten Mal um Genehmigung eines MCP-Servers. Danach können sich Tool-Definitionen zwischen Sitzungen ändern, ohne in allen Fällen erneut abzufragen. Ein Server, der zum Installationszeitpunkt sicher war, kann sich nach einem Update anders verhalten. Die Lücke bei der erneuten Validierung ist strukturell: Das Protokoll verlangt keine kryptografische Signierung der Tool-Beschreibungen.²

4. Supply-Chain-Kompromittierung. In Registries veröffentlichte MCP-Server mit Backdoors, einschließlich Pakete, die sich als legitime Server ausgeben. Dasselbe Supply-Chain-Muster, das wir in Die Lieferkette ist die Angriffsfläche dokumentiert haben, angewandt auf das MCP-Ökosystem.

5. Mandantenübergreifende Exposition. Geteilte Hosting-Umgebungen, in denen mehrere MCP-Server die Funktionsaufrufe der anderen vor der Ausführung abfangen können.⁴ Isolationsgrenzen, die von außen stabil wirken, brechen zusammen, wenn sich mehrere Server einen Prozess oder Container teilen.

Das SSRF-Muster

Drei SSRF-Schwachstellen in drei verschiedenen MCP-Servern kamen in dieser Woche bei einem einzigen Scan ans Licht:³

• n8n-mcp: Authentifizierte SSRF über Instance-Host-Injection
• mcp-from-openapi: SSRF über $ref-Werte in OpenAPI-Spezifikationen. Eine bösartige Spezifikation mit internen URLs veranlasst den Server, diese Ressourcen während der Initialisierung abzurufen
• stata-mcp: Unzureichende Validierung benutzerseitig bereitgestellter URLs

SSRF in MCP-Servern ist besonders gefährlich, weil der Server typischerweise über Netzwerkzugriff verfügt, den der Agent nicht hat. So wird aus einer einzigen bösartigen OpenAPI-Spezifikation der Diebstahl von Zugangsdaten:

Schritt 1. Ein Angreifer veröffentlicht einen legitim wirkenden MCP-Server, der eine externe API umhüllt. Der Server nutzt mcp-from-openapi, um Tools aus einer OpenAPI-Spezifikation zu generieren.

Schritt 2. Die OpenAPI-Spezifikation enthält eine $ref, die auf eine interne Adresse zeigt:

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

Schritt 3. Während initialize() löst der MCP-Server die $ref auf, indem er die URL abruft. Der Server läuft auf Ihrer Infrastruktur: in Ihrer VPC, auf Ihrem Laptop, in Ihrem CI-Container. Die Anfrage geht aus einer vertrauenswürdigen Quelle an den AWS-Metadaten-Endpunkt.

Schritt 4. Der Metadaten-Endpunkt gibt temporäre IAM-Zugangsdaten zurück: Access Key, Secret Key, Session Token.

Schritt 5. Der Server verfügt nun über Ihre Cloud-Zugangsdaten. Er kann sie in Tool-Antworten ausschleusen, an einen externen Endpunkt loggen oder direkt verwenden.

Der Agent hat nie etwas Bösartiges getan. Der Benutzer hat den MCP-Server genehmigt. Die OpenAPI-Spezifikation sah normal aus. Die $ref-Auflösung geschah auf Bibliotheksebene, unterhalb dessen, was irgendjemand prüft. Die SSRF verwandelte die Netzwerkposition des MCP-Servers in die Netzwerkposition des Angreifers.

Microsoft patchte im März 2026 eine kritische Azure-MCP-SSRF (CVE-2026-26118). Dasselbe Muster galt für Azure: eine Elevation-of-Privilege-Schwachstelle mit hohem Schweregrad, die Authentifizierungstoken stehlen und unbefugten Zugriff auf Azure-Ressourcen gewähren konnte.⁵

Was zu tun ist

Prüfen Sie Ihre verbundenen Server. Führen Sie claude mcp list aus und überprüfen Sie jeden Server. Gleichen Sie jeden mit der Datenbank des Vulnerable MCP Project ab.¹ Entfernen Sie Server, die Sie nicht aktiv nutzen.

Pinnen Sie Server-Versionen. Wenn Sie MCP-Server von npm oder pip installieren, pinnen Sie die Version. Aktualisieren Sie nicht automatisch. Prüfen Sie Changelogs vor einem Upgrade. Das Muster der Vertrauensumgehung bedeutet, dass ein Update Tool-Definitionen ohne erneute Genehmigung ändern kann.

Fügen Sie Hooks zur Eingabevalidierung hinzu. Ein PreToolUse-Hook auf MCP-Toolaufrufe kann Eingaben validieren, bevor sie den Server erreichen:

#!/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

Ziehen Sie Transport-Isolation in Betracht. Die Laufzeit-Verteidigungsmuster für tool-erweiterte Agenten sind hier unmittelbar anwendbar: Jeder MCP-Server ist ein Werkzeug, das der Agent aufruft, und die Verteidigungsarchitektur muss kompromittierte Werkzeuge einkalkulieren. HTTP-MCP-Server laufen in ihrem eigenen Prozess mit expliziten Netzwerkgrenzen. Stdio-Server teilen sich den Prozesskontext des Agenten. Kein Transport ist an sich sicher. Der größere Faktor ist, ob der Server Zugriff auf Zugangsdaten, interne Netzwerke oder sensible Dateipfade hat. Wählen Sie den Transport, der Ihnen die Isolationsgrenzen liefert, die Ihr Bedrohungsmodell erfordert.

Beobachten Sie die Datenbank. Das Vulnerable MCP Project unter vulnerablemcp.info kommt einem CVE-Tracker für das MCP-Ökosystem am nächsten. Konsultieren Sie es, bevor Sie neue Server installieren.

Das MCP-Ökosystem wächst rasant: mehr als 3.000 indexierte Server und 100 Millionen monatliche Downloads.⁶ Die Sicherheitslage wächst nicht mit. Fünfzig Schwachstellen in einer Datenbank, die es vor einem Jahr noch nicht gab. Das Protokoll ist nicht das Problem. Die Implementierungen sind es. Und wie ich in Ihr Agent hat einen Mittelsmann dokumentiert habe, ist jeder Zwischenakteur in der Tool-Kette des Agenten eine Gelegenheit zur Interception, die die meisten Entwickler nie prüfen.

Quellen

Häufig gestellte Fragen

Sind die mit Claude Code gebündelten MCP-Server betroffen?

Die Schwachstellen betreffen in erster Linie community-entwickelte und Drittanbieter-MCP-Server, nicht die zentrale Claude Code-MCP-Infrastruktur. Allerdings hatte das offizielle MCP Inspector Tool eine RCE-Schwachstelle, sodass „offiziell” nicht „immun” bedeutet.

Sollte ich die Nutzung von MCP-Servern einstellen?

Nein. MCP ist eine leistungsstarke Integrationsschicht. Behandeln Sie jedoch jeden MCP-Server als Vertrauensgrenze. Prüfen Sie, was Sie verbunden haben, pinnen Sie Versionen und fügen Sie Hooks zur Eingabevalidierung für Server hinzu, die URLs, Dateipfade oder Shell-Befehle entgegennehmen.

Wie überprüfe ich, ob meine MCP-Server anfällig sind?

Führen Sie claude mcp list aus, um Ihre verbundenen Server zu sehen. Gleichen Sie jeden mit der Datenbank des Vulnerable MCP Project ab. Prüfen Sie das GitHub-Repository des Servers auf aktuelle Sicherheitshinweise.