Dreißig CVEs in sechzig Tagen. Zwischen Januar und Februar 2026 wandelte sich das Model Context Protocol vom vielversprechenden Integrationsstandard zur am schnellsten wachsenden Angriffsfläche im KI-Stack. Die CVEs waren keine theoretischen Befunde aus akademischen Papers. Sie umfassten eine CVSS-9.6-Remote-Code-Execution in einem Paket mit über 437.000 Downloads, eine Azure-MCP-SSRF, mit der Angreifer Managed-Identity-Tokens stehlen konnten, und Token Securitys Demonstration einer vollständig nutzerinteraktionsfreien RCE-Kette auf der RSAC 2026, bei der eine präparierte Google-Docs-Datei Cloud-Secrets abgreifen konnte, ohne dass jemand klicken musste.
Der 60-Tage-Ausbruch war kein Zufall. Er war das unvermeidliche Ergebnis eines Protokolls, das über 10.000 öffentliche Server-Implementierungen erreichte, bevor systematisch geprüft wurde, was diese Server tatsächlich preisgeben. BlueRock scannte 7.000 MCP-Server und fand 36,7 % anfällig für SSRF. Qualys bezeichnete MCP-Server als „die neue Schatten-IT." Und CoSAI veröffentlichte ein Whitepaper mit 12 Bedrohungskategorien und 40 konkreten Bedrohungen, die die meisten Organisationen nicht adressieren.
Warum 30 CVEs in 60 Tagen passierten
Der Schwachstellen-Ausbruch entstand nicht, weil Forscher plötzlich auf MCP aufmerksam wurden. Drei strukturelle Faktoren trafen Anfang 2026 zusammen.
Das Problem der Anthropic-Referenzimplementierung
Im Januar 2026 veröffentlichte Sicherheitsforscher Yarden Porat drei CVEs in Anthropics eigenem mcp-server-git: CVE-2025-68143 (CVSS 8,8), CVE-2025-68144 (CVSS 8,1) und CVE-2025-68145 (CVSS 7,1). Der Kern des Problems: Das --repository-Flag, das Dateioperationen auf ein bestimmtes Verzeichnis beschränken sollte, wurde nie erzwungen. Anthropics Fix für git_init war radikal: Sie entfernten das Tool komplett.
Das reicht über die konkreten Bugs hinaus. Hunderte Drittanbieter-MCP-Server wurden gebaut, indem sie Muster aus Anthropics Referenzimplementierungen kopierten. Als der Referenzcode keine Input-Validierung und keine Pfadbegrenzung hatte, verbreiteten sich diese Muster im gesamten Ökosystem. Die 30 CVEs waren nicht 30 unabhängige Bugs, sondern Variationen derselben architektonischen Abkürzungen in verschiedenen Codebases.
Der SDK-Response-Leakage-Fehler
CVE-2026-25536 (CVSS 7,1) betraf das offizielle MCP TypeScript SDK selbst, nicht einen Drittanbieter-Server. Wenn eine einzelne McpServer-Instanz mit StreamableHTTPServerTransport mehrere Client-Verbindungen handhabte, führten JSON-RPC-Message-ID-Kollisionen dazu, dass Antworten an den falschen Client geleitet wurden. Client A erhielt die Daten von Client B.
Für Unternehmen, die ein zentralisiertes MCP-Gateway betreiben (genau die Architektur, die viele Anbieter empfehlen), war das ein Weckruf: Das SDK selbst konnte das Mandantenfähigkeits-Muster nicht sicher handhaben.
43 % der CVEs waren Shell-Injection
Endor Labs analysierte 2.614 MCP-Implementierungen und stellte fest, dass 43 % der CVEs Exec/Shell-Injection betrafen. Keine neuartigen KI-Angriffe, sondern klassische CWE-78- und CWE-94-Schwachstellen, die das BSI und OWASP seit Jahrzehnten dokumentieren. Der Unterschied: MCPs Architektur gibt LLM-generierte Zeichenketten konzeptionell an Systemoperationen weiter. Jede nicht validierte Eingabe wird zum Injection-Vektor, wenn der Zweck des Protokolls darin besteht, KI-Agenten Tool-Aufrufe ausführen zu lassen.
Die Aufschlüsselung spricht für sich:
- 43 % Exec/Shell-Injection (CWE-78, CWE-94)
- 36,7 % Server-Side Request Forgery (SSRF)
- 10 % Pfad-Traversierung (CWE-22)
- 7 % Cross-Site Scripting (CWE-79)
- 6 % SQL-Injection (CWE-89)
Das sind dieselben Schwachstellenklassen von 2005, jetzt innerhalb von KI-Agenten-Integrationen mit Zugang zu Cloud-Credentials, Datenbanken und internen APIs.
MCPwned: Die Zero-Click-Kette, die das Bedrohungsmodell verändert
Token-Security-Forscher Ariel Simon präsentierte MCPwned auf der RSAC 2026 und zeigte, was passiert, wenn MCP-Schwachstellen mit dem impliziten Vertrauen kombiniert werden, das KI-Agenten ihren Tools entgegenbringen.
Der Angriff beginnt mit einer präparierten Google-Docs-Datei. Ein IDE-Coding-Agent (etwa Cursor oder Claude Code) ruft das Dokument als Kontext ab. Das Dokument enthält versteckte Anweisungen, die den Agenten anweisen, sich mit einem vom Angreifer kontrollierten MCP-Server zu verbinden. Der bösartige Server liefert eine Tool-Antwort mit Python-Payload. Der Agent führt ihn aus. Cloud-Secrets, Umgebungsvariablen und API-Schlüssel werden abgegriffen. Benötigte Nutzerinteraktion: null.
Simon demonstrierte die vollständige Kette gegen CVE-2026-26118, die Azure-MCP-Server-SSRF (CVSS 8,8), die Microsoft im März 2026 Patch Tuesday behob. Die Schwachstelle ermöglichte es, über SSRF das Managed-Identity-Token des MCP-Servers abzufangen und damit Azure-Berechtigungen zu übernehmen. Kombiniert mit der MCPwned-Kette konnte ein Angreifer von „ein geteiltes Dokument" zu „voller Azure-Umgebungszugang" gelangen, ohne dass das Ziel irgendetwas anklickte.
MCP-Server als neue Schatten-IT
Qualys TotalAIs Analyse vom März 2026 nannte MCP-Server „die neue Schatten-IT für KI," und die Einordnung trifft den Punkt. Entwickler starten MCP-Server, um ihre KI-Coding-Assistenten mit internen Tools, Datenbanken und APIs zu verbinden. Die meisten dieser Deployments geschehen außerhalb der Sichtbarkeit des Sicherheitsteams. Kein Inventar. Kein Authentifizierungs-Audit. Keine Netzwerksegmentierungsprüfung.
Für DACH-Unternehmen, die unter der DSGVO und dem EU AI Act operieren, ist das ein besonderes Risiko: MCP-Server können personenbezogene Daten verarbeiten, ohne dass die zuständige Datenschutzstelle davon weiß. Wenn ein KI-Agent über einen MCP-Server auf Kundendaten zugreift und diese in eine LLM-Prompt fließen, liegt potenziell eine Datenverarbeitung vor, die in keinem Verzeichnis von Verarbeitungstätigkeiten erfasst ist.
Die Qualys-Forschung identifizierte drei Ebenen der Exposition:
Netzwerk-Entdeckungslücken. MCP-Server laufen auf nicht standardmäßigen Ports, oft hinter Entwickler-Workstations oder CI/CD-Pipelines. Herkömmliche Netzwerk-Scanning-Tools erfassen sie nicht als sicherheitsrelevante Dienste.
Rechte-Eskalation auf Host-Ebene. MCP-Server laufen typischerweise mit denselben Berechtigungen wie das Benutzerkonto des Entwicklers. Wenn dieses Konto AWS-Credentials, Datenbank-Verbindungsstrings oder Produktions-API-Schlüssel in seinen Umgebungsvariablen hat, erbt jeder MCP-Server diesen Zugang.
Supply-Chain-Intransparenz. Das durchschnittliche MCP-Deployment bezieht 3-5 Community-gebaute Server von npm oder GitHub. BlueRocks Scan von 7.000 Servern ergab, dass die meisten keine Authentifizierung besitzen und 36,7 % ab Werk SSRF-verwundbar sind.
Was Unternehmen jetzt tun sollten
Die gute Nachricht: Die Schwachstellenklassen in MCP sind gut verstanden. Die schlechte: Die Standard-Sicherheitslage der meisten MCP-Deployments ist „weit offen." Hier eine konkrete Checkliste basierend auf dem CoSAI-Framework und Hersteller-Empfehlungen von Red Hat und Palo Alto Networks.
Jeden MCP-Server inventarisieren
Was nicht sichtbar ist, lässt sich nicht absichern. Nutzen Sie Qualys TotalAI oder vergleichbare Tools, um MCP-Server in Ihrem Netzwerk zu entdecken. Prüfen Sie Entwickler-Workstations, CI/CD-Runner und jede Maschine, auf der ein KI-Coding-Assistent läuft. Wenn Sie MCP-Server finden, von denen Sie nichts wussten, haben Sie ein Schatten-IT-Problem, das sofortige Aufmerksamkeit erfordert.
Authentifizierung auf jedem Endpunkt erzwingen
Nur 8,5 % der MCP-Server implementieren OAuth, und 38-41 % haben überhaupt keine Authentifizierung. Jeder MCP-Server in Ihrer Umgebung braucht Authentifizierung. Nutzen Sie BlueRocks MCP Trust Registry für eine Positivliste genehmigter Server und blockieren Sie nicht genehmigte Verbindungen.
Alle Eingaben an der Server-Grenze validieren
Die 43-%-Shell-Injection-Rate existiert, weil MCP-Server LLM-generierte Zeichenketten direkt an Systemaufrufe weiterleiten. Jeder MCP-Server-Tool-Handler muss Eingaben validieren und bereinigen, bevor er Operationen ausführt. Behandeln Sie alle Tool-Call-Parameter als nicht vertrauenswürdige Benutzereingaben, denn genau das sind sie.
SDK-Versionen pinnen und Abhängigkeiten scannen
CVE-2026-25536 im MCP TypeScript SDK zeigt, dass die Bibliotheken des Protokolls selbst Schwachstellen einführen können. Pinnen Sie Ihre SDK-Versionen, führen Sie Snyk Agent Scan oder vergleichbare Tools gegen Ihre MCP-Abhängigkeiten aus und abonnieren Sie die MCP-GitHub-Security-Advisories.
MCP-Netzwerkzugang segmentieren
MCP-Server sollten keinen Zugang zu Ihrem gesamten internen Netzwerk haben. Wenden Sie Least-Privilege-Netzwerkrichtlinien an: Beschränken Sie ausgehende Verbindungen auf die spezifischen Dienste, die jeder Server benötigt. Das verhindert, dass SSRF-Angriffe über MCP-Server zu internen Metadaten-Endpunkten, Cloud-Credential-Diensten oder Datenbanken pivotieren.
Das strukturelle Problem, das MCP nicht gelöst hat
Die 30 CVEs in 60 Tagen legten eine Lücke offen, die kein Patch-Zyklus vollständig schließen kann: MCPs Vertrauensmodell geht davon aus, dass Tool-Beschreibungen ehrlich sind und Server sich wie angekündigt verhalten. Es gibt keinen eingebauten Mechanismus zur Überprüfung der Tool-Integrität, keine kryptographische Signierung von Tool-Schemas und keine Möglichkeit für einen Client, zu bestätigen, dass das Verhalten eines Servers seiner Beschreibung entspricht.
Anthropics MCP-Spezifikation definiert Transport und Nachrichtenformat, überlässt aber Authentifizierung, Autorisierung und Tool-Verifikation vollständig den Implementierern. Wenn über 10.000 Server von verschiedenen Teams mit unterschiedlichen Sicherheitsprioritäten gebaut werden, ist das Ergebnis vorhersehbar: Die schwächsten Implementierungen setzen die effektive Sicherheitsschwelle für das gesamte Ökosystem.
CoSAIs 12 Bedrohungskategorien kartieren diese strukturelle Lücke präzise. Die fundamentalsten: Tool-Beschreibungsintegrität (keine Möglichkeit zu verifizieren, dass ein Tool das tut, was es behauptet), Credential-Boundary-Enforcement (Server erben Host-Credentials standardmäßig) und Multi-Tenant-Isolation (das SDK selbst hatte den CVE-2026-25536-Response-Leakage-Bug).
Solange MCP keine verpflichtende Authentifizierung, kryptographische Tool-Signierung und eingebaute Mandantenisolierung bekommt, sind diese 30 CVEs eine Vorschau, kein Abschluss. Das Protokoll ist nützlich. Das Protokoll ist weit verbreitet. Und die Sicherheitsfläche des Protokolls wächst schneller als die Fähigkeit der Community, sie abzusichern.
Häufig gestellte Fragen
Warum wurden 30 MCP-CVEs in nur 60 Tagen eingereicht?
Drei Faktoren trafen zusammen: Anthropics Referenzimplementierungen hatten fehlende Input-Validierung, die in Hunderte von Drittanbieter-Servern kopiert wurde. Das MCP TypeScript SDK selbst hatte einen Multi-Tenant-Response-Leakage-Bug (CVE-2026-25536). Und das Protokoll erreichte über 10.000 öffentliche Server-Implementierungen, bevor systematische Sicherheitsaudits nachkamen. 43 % der CVEs waren klassische Shell-Injection-Schwachstellen.
Was ist MCPwned und wie funktioniert der Zero-Click-Angriff?
MCPwned ist eine Schwachstellenforschung von Token Security, präsentiert auf der RSAC 2026. Sie demonstriert eine Zero-Click-RCE-Kette, bei der eine präparierte Google-Docs-Datei einen IDE-Coding-Agenten veranlasst, sich mit einem vom Angreifer kontrollierten MCP-Server zu verbinden, einen Python-Payload auszuführen und Cloud-Secrets abzugreifen. Keine Nutzerinteraktion erforderlich.
Welcher Prozentsatz der MCP-Server ist anfällig für SSRF?
BlueRock scannte über 7.000 MCP-Server und fand 36,7 % mit potenziellen SSRF-Schwachstellen. Darunter der Microsoft MarkItDown MCP-Server und der Azure MCP-Server (CVE-2026-26118, CVSS 8,8), der ausgenutzt werden konnte, um Managed-Identity-Tokens zu stehlen und unautorisierten Zugang zu Azure-Ressourcen zu erlangen.
Warum nennt Qualys MCP-Server “die neue Schatten-IT”?
Entwickler starten MCP-Server, um KI-Coding-Assistenten mit internen Tools und APIs zu verbinden, typischerweise außerhalb der Sichtbarkeit des Sicherheitsteams. Diese Server laufen auf nicht standardmäßigen Ports, erben die Credentials und Berechtigungen des Entwicklers und beziehen Community-gebaute Abhängigkeiten ohne Authentifizierung. Die meisten Organisationen haben kein Inventar der MCP-Server in ihrer Umgebung.
Welche besonderen Risiken bestehen für DACH-Unternehmen?
Unter der DSGVO und dem EU AI Act können MCP-Server personenbezogene Daten verarbeiten, ohne dass die Datenschutzstelle davon weiß. Wenn ein KI-Agent über MCP auf Kundendaten zugreift und diese in LLM-Prompts fließen, liegt potenziell eine nicht dokumentierte Datenverarbeitung vor. Unternehmen müssen MCP-Server in ihr Verzeichnis von Verarbeitungstätigkeiten aufnehmen und sicherstellen, dass die Rechtsgrundlage für die Datenverarbeitung geklärt ist.