200.000 MCP-Server gefährdet durch kritische Sicherheitslücke

Das Model Context Protocol (MCP) von Anthropic gilt seit seiner Einführung als offener Standard für die Kommunikation zwischen KI-Agenten und Tools. OpenAI, Google DeepMind und andere große Tech-Firmen haben den Standard übernommen, nachdem Anthropic ihn im Dezember 2025 der Linux Foundation übergab. Mit über 150 Millionen Downloads entwickelte sich MCP zur zentralen Schnittstelle für KI-gestützte Anwendungen. Doch jetzt deckten vier Sicherheitsforscher von OX Security eine systemische Schwachstelle auf, die das gesamte Ökosystem betrifft.

Die Schwachstelle: STDIO-Transport ermöglicht beliebige Code-Ausführung

Die zentrale Architektur-Schwachstelle liegt im STDIO-Transport, der Standardmethode für die Verbindung zwischen KI-Agenten und lokalen Tools. MCP führt jeden erhaltenen Betriebssystembefehl ohne Überprüfung aus – selbst wenn dieser schädlich ist. Es gibt keine klare Trennung zwischen Konfiguration und Ausführung, und selbst wenn ein Befehl einen Fehler zurückgibt, wurde er bereits ausgeführt. Die Entwicklerwerkzeuge erkennen diesen Vorgang nicht als potenzielle Sicherheitsgefahr.

OX Security durchsuchte die MCP-Landschaft und identifizierte 7.000 öffentlich erreichbare Server mit aktivem STDIO-Transport. Hochgerechnet auf die gesamte Infrastruktur könnten bis zu 200.000 Instanzen betroffen sein. Die Forscher bestätigten zudem die willkürliche Code-Ausführung auf sechs produktiven Plattformen mit zahlenden Kunden. Die Analyse führte zur Identifizierung von mehr als zehn kritischen CVEs, die Produkte wie LiteLLM, LangFlow, Flowise, Windsurf und Langchain-Chatchat betreffen.

Kevin Curran, IEEE-Senior Member und Professor für Cybersecurity an der Ulster University, bewertete die Forschungsergebnisse als „erschütternden Missstand in der Sicherheit von grundlegender KI-Infrastruktur“.

Anthropic: „Erwartetes Verhalten“ – keine Änderungen am Protokoll

Anthropic bestätigte, dass die Sicherheitslücke kein Bug, sondern ein Designmerkmal ist. Das Unternehmen lehnte eine Anpassung des MCP-Standards ab und betonte, dass die STDIO-Ausführungsumgebung als sicherer Standard zu betrachten sei. Die Verantwortung für die Eingabesanierung liege beim Entwickler. In einer offiziellen Stellungnahme heißt es nur: „Dieses Verhalten ist erwartet.“

OX Security widerspricht dieser Einschätzung vehement. Die Forderung, dass 200.000 Entwickler die Eingaben korrekt bereinigen, sei unrealistisch. Anthropics technischer Einwand, dass eine Sanierung entweder den Transport brechen oder die Payload nur um eine Ebene verschieben würde, sei zwar technisch nachvollziehbar – doch die Debatte um die richtige Lösung dauert an.

Wie Sie Ihre MCP-Infrastruktur auf Sicherheitsrisiken prüfen

Die Sicherheitslücke betrifft nicht nur einzelne Produkte, sondern das gesamte Ökosystem. Jedes Projekt, das auf das MCP-Protokoll vertraut, hat die Schwachstelle übernommen. OX Security identifizierte vier Hauptangriffsszenarien:

• Unauthentifizierte Code-Injektion über KI-Framework-Webinterfaces
• Betrifft Produkte wie LangFlow und LiteLLM, die über öffentliche Schnittstellen angreifbar sind.

• Umgehung von Allowlists durch Argument-Injektion
• Tools wie Flowise und Upsonic implementieren Command-Allowlists – doch Angreifer können diese durch geschickte Argumentübergabe (z. B. über npx -c) umgehen.

• Zero-Click-Prompt-Injection in KI-Entwickler-IDE
• Schädliche HTML-Inhalte können lokale MCP-Konfigurationsdateien modifizieren und Code ausführen.
• Windsurf (CVE-2026-30615) ist die einzige IDE, bei der die Ausführung ohne Benutzerinteraktion erfolgt. Cursor, Claude Code und Gemini-CLI sind ebenfalls betroffen, erfordern jedoch mindestens eine Benutzeraktion.

• Verteilung schädlicher Pakete über MCP-Registries
• OX reichte ein scheinbar harmloses Proof-of-Concept bei elf Registries ein – neun akzeptierten es ohne Sicherheitsprüfung.

Carter Rees, VP für KI und Machine Learning bei Reputation und Mitglied der Utah AI Commission, warnt: „STDIO im MCP ist eine privilegierte Ausführungsoberfläche, kein einfacher Konnektor. Unternehmen sollten es wie direkten Shell-Zugriff behandeln: Standardmäßig blockieren, Allowlists nutzen, Sandboxing einsetzen und nicht auf nachgelagerte Eingabevalidierung vertrauen.“

Patch-Status: Wer hat die Schwachstelle behoben?

Die Lückenverteilung ist ungleich: Einige Anbieter haben Patches veröffentlicht, andere nur Teilabhilfen oder noch keine Stellungnahme abgegeben. Die folgende Übersicht zeigt den aktuellen Stand für die betroffenen Produkte:

Product | Exploit-Typ | Patch verfügbar? | Protokoll-Fix? | Verbleibende Lücke | Empfohlene Maßnahme --- | --- | --- | --- | --- | --- LiteLLM | Command-Injection über Adapter-UI | JA | NEIN | Neue STDIO-Konfigurationen außerhalb von LiteLLM erben denselben unsicheren Standard | Auf Version v1.83.7-stable oder höher aktualisieren (CVE-2026-30623). Alle STDIO-Definitionen auditieren. LangFlow | RCE über öffentliche Auto-Login + STDIO | TEILWEISE | NEIN | Kein vollständiger Schutz gegen alle Angriffsvektoren | Konfigurationen überprüfen und auf neueste Version updaten. Flowise | Umgehung von Allowlists | NEIN | NEIN | Hardening-Mechanismen können durch Argument-Injektion umgangen werden | Lokale Allowlists durch dynamische Sandboxing-Lösungen ersetzen. Windsurf | Zero-Click-Code-Ausführung | JA | NEIN | Kein Schutz vor Konfigurationsänderungen durch externe HTML-Inhalte | IDE-Konfigurationen manuell prüfen und auf neueste Version updaten.

Wichtig: Kein Produkt hat die zugrundeliegende Protokoll-Schwachstelle behoben. Selbst gepatchte Versionen bleiben anfällig, solange der STDIO-Transport aktiv ist. Sicherheitsverantwortliche müssen daher nicht nur einzelne Produkte, sondern die gesamte MCP-Infrastruktur überprüfen.

Handlungsempfehlungen für Sicherheitsverantwortliche

Die MCP-Sicherheitslücke stellt eine unterschätzte Bedrohung für Unternehmensumgebungen dar. Hier sind konkrete Schritte für den Umgang mit dem Risiko:

• Inventarisierung der MCP-Infrastruktur
• Alle KI-Agenten und Tools identifizieren, die MCP nutzen.
• STDIO-Transport deaktivieren oder auf alternative Transportmethoden umstellen (z. B. HTTP oder gRPC).

• Sandboxing und Access Control
• MCP-Tools in isolierten Umgebungen ausführen.
• Strenge Allowlists für Befehle und Argumente implementieren.
• Keine öffentlichen Endpunkte ohne Authentifizierung zulassen.

• Konfiguration und Monitoring
• Lokale MCP-Konfigurationsdateien regelmäßig auf unautorisierte Änderungen prüfen.
• Logs auf verdächtige STDIO-Aktivitäten überwachen.

• Schulung und Sensibilisierung
• Entwickler über die Risiken von MCP und STDIO aufklären.
• Zero-Trust-Prinzipien bei der KI-Tool-Nutzung anwenden.

Die Debatte um die Zukunft des MCP-Standards wird weitergehen – doch für Unternehmen ist jetzt Handeln angesagt. Die 200.000 potenziell gefährdeten Instanzen warten nicht auf eine Lösung aus der Industrie. Es liegt in der Verantwortung jeder Organisation, die eigene MCP-Infrastruktur zu sichern und nicht auf nachträgliche Patches zu vertrauen.