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 innerhalb von 60 Tagen eingereicht. Von 2.614 untersuchten MCP-Implementierungen wiesen 82 % Schwachstellen bei Dateioperationen auf, die anfällig für Path Traversal waren. Zwischen 38 % und 41 % der Server verfügten über keinerlei Authentifizierung.² Das offizielle MCP-Inspector-Tool — das Werkzeug, mit dem Entwickler MCP-Server debuggen — hatte eine RCE-Schwachstelle. Das weit verbreitete Paket mcp-remote enthielt einen OS-Command-Injection-Bug.¹

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.

Zusammenfassung

MCP-Server sind die am schnellsten wachsende Integrationsschicht im Agenten-Ökosystem — und zugleich die am wenigsten geprüfte. Die Schwachstellendatenbank enthält 50 Einträge: 13 kritisch, 32 hoch. Eingabevalidierungsfehler und Prompt Injection machen 30 der 50 aus. Drei SSRF-Schwachstellen in drei verschiedenen MCP-Servern tauchten diese Woche an einem einzigen Tag auf.³ Das Muster ist eindeutig: Die Community veröffentlicht MCP-Server schneller, als sie diese überprüft.

Die wichtigsten Erkenntnisse

• Claude Code-Nutzer: Jeder MCP-Server, den Sie verbinden, ist eine Vertrauensgrenze, die Sie erweitern. Führen Sie jetzt claude mcp list aus und prüfen Sie, was verbunden ist. Falls Sie Community-MCP-Server nutzen, die Sie vor Monaten installiert haben, überprüfen Sie, ob seitdem Patches veröffentlicht wurden.
• Harness-Entwickler: Ihre PreToolUse-Hooks sind die letzte Verteidigungslinie, bevor ein MCP-Tool-Aufruf einen ungeprüften Server erreicht. Erwägen Sie Hooks, 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, dass „SHOULD always be a human in the loop.” Behandeln Sie das als MUST. Validieren Sie alle Eingaben. Übergeben Sie niemals benutzergesteuerte Zeichenketten über String-Interpolation an Shell-Befehle. Vertrauen Sie $ref-Werten in OpenAPI-Spezifikationen niemals 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 trugen Erkenntnisse bei. Zu den betroffenen Servern gehören Anthropics eigener Git-MCP-Server, der offizielle MCP-Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes sowie über 20 Community-Server.¹

Das Ergebnis der Umfrage ist besonders alarmierend: 82 % von 2.614 MCP-Implementierungen wiesen Schwachstellen bei Dateioperationen auf, die anfällig für Path Traversal waren.² Vier von fünf MCP-Servern ermöglichen es einem Angreifer, Dateien zu lesen, auf die er keinen Zugriff haben sollte.

Fünf Angriffsmuster

Die 60-tägige CVE-Welle offenbarte fünf wiederkehrende Muster:²

1. Tool Poisoning. Bösartige Anweisungen, eingebettet in MCP-Tool-Beschreibungen. Der Agent liest die Beschreibung, vertraut ihr und befolgt die versteckten Anweisungen mit seinen eigenen autorisierten Tools. Das manipulierte Tool wird nie ausgeführt — die legitimen Tools des Agenten führen den Angriff aus. Dieses Muster haben wir im Deploy-and-Defend-Paradoxon behandelt: Das Vertrauen ist transitiv, die Prüfung hingegen nicht.

2. Prompt Injection über externe Daten. MCP-Server, die Inhalte aus GitHub-Issues, Slack-Nachrichten, E-Mails oder Webseiten abrufen, bringen angreifergesteuerten 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. Vertrauensumgehung nach erstmaliger Genehmigung. Claude Code bittet Sie beim ersten Mal um Genehmigung eines MCP-Servers. Danach können sich Tool-Definitionen zwischen Sitzungen ändern, ohne dass in allen Fällen erneut nachgefragt wird — ein Server, der bei der Installation sicher war, kann sich nach einem Update anders verhalten. Die Lücke bei der Revalidierung ist strukturell bedingt: Das Protokoll erfordert keine kryptographische Signierung von Tool-Beschreibungen.²

4. Kompromittierung der Lieferkette. Mit Hintertüren versehene MCP-Server, die in Registries veröffentlicht werden — einschließlich Pakete, die legitime Server imitieren. Dasselbe Lieferkettenmuster, das wir in Die Lieferkette ist die Angriffsfläche dokumentiert haben, angewandt auf das MCP-Ökosystem.

5. Mandantenübergreifende Offenlegung. Shared-Hosting-Umgebungen, in denen mehrere MCP-Server gegenseitig ihre Funktionsaufrufe vor der Ausführung abfangen können.⁴ Isolationsgrenzen, die von außen solide erscheinen, brechen zusammen, wenn mehrere Server sich einen Prozess oder Container teilen.

Das SSRF-Muster

Drei SSRF-Schwachstellen in drei verschiedenen MCP-Servern tauchten diese Woche bei einem einzigen Scan auf:³

• n8n-mcp: Authentifiziertes 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 benutzerbereitgestellter URLs

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

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

Schritt 2. Die OpenAPI-Spezifikation enthält einen $ref, der 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 den $ref auf, indem er die URL abruft. Der Server läuft auf Ihrer Infrastruktur — innerhalb Ihrer VPC, auf Ihrem Laptop, in Ihrem CI-Container. Die Anfrage geht von einer vertrauenswürdigen Quelle an den AWS-Metadaten-Endpunkt.

Schritt 4. Der Metadaten-Endpunkt gibt temporäre IAM-Anmeldedaten zurück: Zugriffsschlüssel, geheimen Schlüssel und Sitzungstoken.

Schritt 5. Der Server hat nun Ihre Cloud-Anmeldedaten. Er kann sie über Tool-Antworten exfiltrieren, an einen externen Endpunkt protokollieren oder direkt verwenden.

Der Agent hat nichts 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 überprüft. Das SSRF wandelte die Netzwerkposition des MCP-Servers in die Netzwerkposition des Angreifers um.

Microsoft hat im März 2026 ein kritisches Azure-MCP-SSRF (CVE-2026-26118) gepatcht — dasselbe Muster, angewandt auf Azure: eine hochgradige Schwachstelle zur Rechteausweitung, die Authentifizierungstoken stehlen und unbefugten Zugriff auf Azure-Ressourcen gewähren konnte.⁵

Was Sie tun sollten

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 über npm oder pip installieren, pinnen Sie die Version. Aktivieren Sie keine automatischen Updates. Prüfen Sie Changelogs vor dem Upgrade — das Vertrauensumgehungsmuster bedeutet, dass ein Update Tool-Definitionen ohne erneute Genehmigung ändern kann.

Fügen Sie Hooks zur Eingabevalidierung hinzu. Ein PreToolUse-Hook für MCP-Tool-Aufrufe 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

Erwägen Sie Transportisolierung. HTTP-MCP-Server laufen in einem eigenen Prozess mit expliziten Netzwerkgrenzen. Stdio-Server teilen den Prozesskontext des Agenten. Keiner der beiden Transporte ist von Natur aus sicher — entscheidender ist, ob der Server Zugriff auf Anmeldedaten, interne Netzwerke oder sensible Dateipfade hat. Wählen Sie den Transport, der die Isolationsgrenzen bietet, die Ihr Bedrohungsmodell erfordert.

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

Das MCP-Ökosystem wächst rasant — über 3.000 indexierte Server und 100 Millionen monatliche Downloads.⁶ Die Sicherheitslage hält damit nicht Schritt. Fünfzig Schwachstellen in einer Datenbank, die vor einem Jahr noch nicht existierte. Das Protokoll ist nicht das Problem. Die Implementierungen sind es.

Quellen

Häufig gestellte Fragen

Sind die in Claude Code integrierten MCP-Server betroffen?

Die Schwachstellen betreffen in erster Linie Community- und Drittanbieter-MCP-Server, nicht die MCP-Kerninfrastruktur von Claude Code. Allerdings hatte das offizielle MCP-Inspector-Tool eine RCE-Schwachstelle — „offiziell” bedeutet also nicht „immun”.

Sollte ich aufhören, MCP-Server zu verwenden?

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

Wie prüfe ich, ob meine MCP-Server verwundbar sind?

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