MCP-Schwachstelle betrifft 7.000 Server und 150 Millionen Downloads in der KI-Lieferkette

Eine architektonische Entscheidung in Anthropics Model Context Protocol hat sich auf mehr als 7.000 öffentlich zugängliche Server und Softwarepakete mit über 150 Millionen Downloads ausgebreitet. Das ist der Schadensradius, den OX Security einer einzigen „by design"-Schwachstelle im STDIO-Transport von MCP zuschreibt – und sie betrifft alle offiziell unterstützten SDK-Sprachen: Python, TypeScript, Java und Rust. Von den elf CVEs, die auf diese Grundursache zurückgehen, sind drei gepatcht. Acht sind es nicht.

Die Zahlen

Die entscheidende Kennzahl ist das Verhältnis: 3 von 11 offengelegten CVEs haben derzeit Fixes. LiteLLM (CVE-2026-30623), Bisheng (CVE-2026-33224) und DocsGPT (CVE-2026-26015) haben Patches veröffentlicht. Die verbleibenden acht – GPT Researcher, Agent Zero, Fay Framework, Langchain-Chatchat, Jaaz, Upsonic, Windsurf und Flowise – sind zum Zeitpunkt des OX Security-Berichts offen, wie The Hacker News berichtete. Das entspricht einer Behebungsrate von rund 27 Prozent bei einer Gruppe von Projekten, die gemeinsam einen erheblichen Teil des aktuellen agentischen KI-Stacks antreiben.

Die Zahl von 7.000 Servern bedarf einer näheren Erläuterung. Es handelt sich um öffentlich zugängliche Instanzen – also über das Internet erreichbare Endpunkte, bei denen die Konfiguration-zu-Befehlsausführung via STDIO mit dem richtigen Anfragepfad ausnutzbar ist. Die 150 Millionen Downloads sind kumulierte Paketabrufe über alle betroffenen Projekte hinweg, darunter LiteLLM, LangChain, LangFlow, Flowise, LettaAI und LangBot. Downloads sind ein nachlaufender Indikator für die Bereitstellung, keine Live-Installationsbasis, aber sie definieren eine Obergrenze für die Gefährdung und eine Untergrenze für den Prüfaufwand, den nachgelagerte Teams sich nun selbst schulden.

Zum Vergleich: frühere Einzel-Projekt-RCEs im KI-Tooling-Bereich. CVE-2025-49596 im MCP Inspector, CVE-2026-22252 in LibreChat, CVE-2026-22688 in WeKnora, CVE-2025-54994 in @akoskm/create-mcp-server-stdio und CVE-2025-54136 in Cursor lassen sich laut OX Security-Analyse alle auf dasselbe STDIO-Missbrauchsmuster zurückführen. Das sind mindestens fünf unabhängige Meldungen im vergangenen Jahr zu Varianten desselben Protokollverhaltens – noch vor der aktuellen Gruppe von zehn. Das Signal aus wiederholter, unkoordinierter Neuentdeckung ist eindeutig: Forscher stießen immer wieder gegen dieselbe Wand, und die Wand bewegte sich nicht.

Die Quelle gibt nicht an, wie viele der 7.000 öffentlichen Server aktiv von produktiven Agenten-Workloads genutzt werden und wie viele lediglich Entwicklungs- oder Demo-Deployments sind. Das ist relevant, weil die tatsächlich angreifbare Fläche irgendwo in diesem Bereich liegt. Die Grenze ist klar: höchstens 7.000, mindestens die Teilmenge, die bereits in öffentlichen Scannern erfasst wurde. Wenn die Verfolgung aktiver Ausnutzung dem Muster jüngster Lieferkettenangriffe folgt, ist zu erwarten, dass der CISA KEV-Katalog innerhalb von 90 Tagen mindestens eine dieser CVEs aufnimmt.

Was wirklich neu ist

Das Neue hier ist nicht RCE durch Konfigurationsinjektion. Command Injection über nicht vertrauenswürdige Konfigurationseingaben ist eine alte, gut dokumentierte Klasse, und die OWASP Top Ten deckt Injektionskategorien seit über einem Jahrzehnt ab. Neu ist der Übertragungsmechanismus: ein vom Protokollautor veröffentlichtes SDK, identisch über vier Sprachlaufzeiten, das Konfigurationsfelder über den STDIO-Transport in OS-level-Befehlsausführung umwandelt, wenn ein lokaler STDIO-Server angefordert wird.

OX Securitys Formulierung ist präzise: „Anthropics Model Context Protocol ermöglicht eine direkte Konfiguration-zu-Befehlsausführung über das STDIO-Interface in allen Implementierungen, unabhängig von der Programmiersprache." Der Mechanismus: Der STDIO-Bootstrap wurde so konzipiert, dass er einen lokalen Server startet und das Handle an das LLM zurückgibt. Übergibt man ihm einen Nicht-Server-Befehl, führt er ihn dennoch aus und gibt dann einen Fehler zurück. Der Fehler ist kosmetischer Natur. Die Ausführung hat bereits stattgefunden.

Vier Angriffskategorien verdeutlichen das konkret: nicht authentifizierte und authentifizierte Command Injection via MCP STDIO, nicht authentifizierte Injektion über direkte STDIO-Konfiguration mit Hardening-Bypass, nicht authentifizierte Injektion über MCP-Konfigurationsbearbeitungen durch Zero-Click-Prompt-Injection sowie nicht authentifizierte Injektion über MCP-Marktplätze, bei denen Netzwerkanfragen versteckte STDIO-Konfigurationen auslösen. Die dritte Kategorie ist diejenige, die Plattformverantwortliche aufhorchen lassen sollte. Zero-Click-Prompt-Injection in eine Konfigurationsbearbeitung bedeutet, dass ein Angreifer keine Entwicklermaschine kompromittieren muss – er muss nur Inhalte platzieren, die ein Agent im normalen Betrieb liest.

Das zweite wirklich neue Element ist Anthropics Reaktion. Laut OX Security-Bericht hat Anthropic es abgelehnt, die Protokollarchitektur zu ändern, und das Verhalten als „erwartet" eingestuft. Das ist eine politische Haltung, kein Versehen. Sie verlagert die Sicherheitsverantwortung vom Protokollautor auf jeden nachgelagerten Implementierer in Python, TypeScript, Java und Rust. Die Gegendarstellung der Forscher ist es wert, zitiert zu werden: „Die Verantwortung auf Implementierer zu verlagern überträgt das Risiko nicht. Es verschleiert nur, wer es geschaffen hat."

Was Sicherheitsteams bereits einkalkulieren

Die meisten Plattformteams, die LangChain, LiteLLM oder Flowise in der Produktion einsetzen, behandeln diese Bibliotheken ohnehin als schnelllebig und patch-intensiv. Die Existenz von RCE in einem LangChain-nahen Projekt ist nicht überraschend, und CVE-Feeds in diesem Ökosystem sind seit über einem Jahr sehr aktiv. Dieser Teil ist einkalkuliert.

Was nicht einkalkuliert ist: der Gedanke, dass das Protokoll selbst – nicht die einzelne Bibliothek – das schwache Glied ist. Teams, die ihre Abhängigkeitsgraphen auf Paketebene geprüft und zu dem Schluss gekommen sind: „Wir verwenden gepatchte Versionen" – sie könnten denselben grundlegenden Defekt noch tragen, weil das Muster im Referenz-SDK von Anthropic steckt. Das verändert die Perspektive auf die Behebungsarbeit. Es geht nicht mehr darum, „LiteLLM zu aktualisieren", sondern darum, „jede MCP STDIO-Grenze im eigenen Stack zu prüfen, einschließlich selbst entwickelter Server, die gegen das offizielle SDK gebaut wurden."

Ebenfalls unterschätzt: der Marktplatz-Vektor. Ein MCP-Marktplatz, der Konfigurationen über Netzwerkanfragen bereitstellt und bei dem diese Konfigurationen STDIO-Befehle verstecken können, ist im Grunde ein Software-Distributionskanal ohne eingebettete Signierungsannahme. Wer als CTO einen internen MCP-Marktplatz für das eigene Engineering-Team aufbaut, sollte das Vertrauensmodell dort eher mit einem nicht geprüften npm-Spiegel vergleichen als mit einer kuratierten Enterprise-Registry. Die Entsprechung zu den MITRE ATT&CK-Techniken rund um Supply-Chain-Kompromittierung und Command-and-Scripting-Interpreter-Ausführung ist direkt.

Die wichtigste offene Frage: Wie viele interne, nicht öffentliche MCP-Server in Unternehmen denselben Defekt aufweisen. Die Quelle misst das öffentliche Internet. Private Deployments hinter VPNs oder Service-Meshes liegen per Definition außerhalb dieser Zählung. Meine Arbeitshypothese ist, dass die private Exposition mindestens so groß ist wie die 7.000 öffentlichen und plausiblerweise ein Vielfaches davon beträgt, da MCPs Versprechen die interne Tool-Integration ist.

Die Gegenmeinung

Die gängige Einschätzung lautet, dass Anthropic falsch liegt und dies ein Fehler auf Protokollebene ist. Das Gegenargument: Anthropic könnte technisch gesehen Recht haben, dass STDIO-Transporte von Natur aus lokale Prozesse ausführen und dass eine Vertrauensgrenze innerhalb eines Transports, der für das Starten von Unterprozessen ausgelegt ist, ein kategorialer Fehler ist. Wenn MCP-Konfiguration als vertrauenswürdige Eingabe behandelt wird – genauso wie eine systemd-Unit-Datei oder ein Dockerfile als vertrauenswürdig gilt –, dann ist „Konfiguration führt zur Befehlsausführung" ein Feature, kein Fehler.

Das Problem mit dieser Verteidigung ist operativer, nicht theoretischer Natur. In der Praxis wird MCP-Konfiguration über Netzwerkgrenzen hinweg übermittelt, von LLMs bearbeitet, die auf Nutzeranfragen reagieren, und über Marktplätze verteilt. Die Vertrauensannahme, unter der das Protokoll konzipiert wurde, übersteht die Einsatzmuster nicht, die das Protokoll aktiv fördert. Anthropic kann in der Spezifikation Recht haben und in der realen Welt trotzdem falsch liegen. Das Verhalten als „erwartet" zu bezeichnen beendet die Diskussion genau dort, wo sie beginnen müsste.

Wenn Anthropic diese Linie noch zwei weitere Quartale hält, ist zu erwarten, dass mindestens ein aufsehenerregender Sicherheitsvorfall, der auf eine MCP-Marktplatzkonfiguration zurückgeführt wird, die politische Änderung erzwingt, die die CVE-Welle nicht bewirkt hat.

Die wichtigsten Erkenntnisse

• Elf CVEs gehen auf eine einzige MCP-STDIO-Designentscheidung zurück; zum Zeitpunkt der OX Security-Analyse sind nur drei (LiteLLM, Bisheng, DocsGPT) gepatcht.
• Die Gefährdung umfasst 7.000+ öffentliche Server und 150 Mio.+ Downloads über Python, TypeScript, Java und Rust SDK-Implementierungen.
• Anthropic hat architektonische Änderungen abgelehnt und das Verhalten als „erwartet" eingestuft, wodurch die Behebung auf jeden nachgelagerten Implementierer verlagert wird.
• Die vier Angriffskategorien umfassen Zero-Click-Prompt-Injection in MCP-Konfigurationen und versteckte STDIO-Befehle über Marktplätze, was das Bedrohungsmodell über traditionelles Dependency-Patching hinaus erweitert.
• Überprüfbare Prognose: Wenn mindestens eine der acht ungepatchten CVEs innerhalb von 90 Tagen nach dem 20. April 2026 in den CISA KEV aufgenommen wird, ist zu erwarten, dass Anthropics Haltung zum „erwarteten Verhalten" vor Q3 2026 kippt.