MCP ist kaputt und Anthropic will es nicht reparieren

MCP (Model Context Protocol) hat 97 Millionen Installationen, ist seit Dezember 2025 offizieller Standard unter der Linux Foundation und steckt in Claude Code, GitHub Copilot, Cursor, Windsurf und Gemini-CLI. Und laut OX Security ist es kaputt! Am 16. April 2026 hat die israelische Firma einen Report veröffentlicht, der eine architekturale Schwachstelle in den offiziellen MCP-SDKs dokumentiert. Betroffen sind 150 Millionen Downloads, rund 7.000 öffentlich erreichbare Server und bis zu 200.000 verwundbare Instanzen. Anthropics Reaktion: Das ist so gewollt.

Was das Problem technisch ist

MCP nutzt STDIO als primären Transportmechanismus. Eine KI-Anwendung startet einen MCP-Server als Subprozess und kommuniziert über Standard-Input und Standard-Output. Das Problem liegt in den offiziellen Anthropic-SDKs für Python, TypeScript, Java und Rust: Die SDKs führen Befehle aus, ohne Eingaben zu validieren oder zu bereinigen.

Die OX-Forscher haben vier Schwachstellenklassen identifiziert. Die schwerwiegendste ist Remote Code Execution. Wenn User-Input irgendwo in der Kette zu den StdioServerParameters durchgereicht wird, kann ein Angreifer beliebige Shell-Befehle auf dem System des Opfers ausführen. Das heißt: Zugriff auf lokale Dateien, interne Datenbanken, API-Keys, Chat-Historien.

Die Schwachstelle ist keine klassische Coding-Lücke, die man mit einem Patch fixt. Sie ist ein Architektur-Fehler: Der Execute-First-Validate-Never-Ansatz ist in den SDKs fest verdrahtet. Wer auf Anthropics MCP-SDK baut, erbt das Problem automatisch.

Was mit HTTP/REST-basierten MCP-Servern ist

MCP kennt neben STDIO zwei weitere Transporte: das ältere HTTP+SSE und das seit März 2025 empfohlene Streamable HTTP. Die gute Nachricht vorweg: Der konkrete Execute-First-Bug aus dem OX-Report betrifft primär STDIO, weil dort die SDKs beim Server-Start Shell-Befehle mit Nutzereingaben zusammensetzen. HTTP-Server werden nicht vom Client "gestartet", sondern laufen als eigenständiger Dienst hinter einer URL. Dieser spezifische Angriffsweg fällt bei HTTP weg.

Die schlechte Nachricht: Der HTTP-Transport hat eigene Sicherheitsprobleme, die genauso ernst sind. Je nach Rolle ist die relevante Ebene eine andere.

Seit MCP-Version 2025-03-26 schreibt der Standard OAuth 2.1 als Authorization-Framework für HTTP-Transporte vor. Server-Betreiber müssen Bearer-Tokens validieren, Resource Indicators nach RFC 8707 setzen, Dynamic Client Registration nach RFC 7591 unterstützen und PKCE für Authorization-Code-Flows verpflichtend einsetzen. Sauberer als "kein Auth wie bei STDIO", aber komplex, und komplexe Auth wird falsch implementiert.

Was in der Praxis schiefgeht:

Fehlende Token-Validierung: Mehrere öffentliche MCP-Server haben Bearer-Tokens akzeptiert, ohne Signatur oder Ablauf zu prüfen. Jeder beliebige Token kam durch.
Confused-Deputy-Angriffe: Ein MCP-Server, der selbst wieder als OAuth-Client gegenüber einem Upstream-Dienst auftritt (zum Beispiel GitHub), kann unter Umständen Tokens des falschen Nutzers durchreichen. Die Spec fordert inzwischen Resource Indicators, aber viele Implementierungen hinken hinterher.
DNS-Rebinding auf localhost: Server, die auf 0.0.0.0 oder ohne Origin-Check lauschen, sind über den Browser eines Entwicklers angreifbar. Ein manipulierter Webseiten-Besuch genügt, um lokal laufende Server ohne Authentifizierung zu erreichen.
Session-Hijacking: Streamable-HTTP-Session-IDs waren in frühen SDK-Versionen zu vorhersehbar oder wurden unverschlüsselt übertragen.
Prompt-Injection und Tool-Poisoning: Ein bösartiger Server kann Tool-Beschreibungen so formulieren, dass das LLM Aktionen ausführt, die der Nutzer nicht wollte. Kein Transport-Bug, sondern ein Vertrauensproblem unabhängig von STDIO oder HTTP.

Mitigations: OAuth 2.1 mit PKCE konsequent einsetzen, Resource Indicators nicht weglassen, Tokens mit engem Scope und kurzer Lebensdauer ausstellen, Origin-Header prüfen, lokale Server nur auf 127.0.0.1 binden. Tool-Beschreibungen von unbekannten Drittanbieter-Servern mit derselben Skepsis behandeln wie NPM-Pakete aus unbekannter Quelle.

Die OX-Schwachstelle ist also kein Argument, einfach von STDIO auf HTTP umzuschalten. Sie ist ein Argument dafür, MCP insgesamt mit mehr Vorsicht zu betreiben, egal welcher Transport.

Welche Tools konkret betroffen sind

OX Security nennt konkrete Produkte in der Supply Chain:

IDE-Coding-Tools: Claude Code, GitHub Copilot, Cursor, Windsurf, Gemini-CLI, VS Code
Low-Code-Frameworks: LangFlow (alle Versionen, IBM), Flowise
Open-Source-Agents: GPT Researcher, Upsonic
MCP-Marktplätze: Neun von elf untersuchten Plattformen

Über 30 verantwortliche Offenlegungen hat OX parallel durchgeführt, mindestens zehn davon führten zu High- oder Critical-CVEs bei einzelnen Projekten. Die Projekte haben gepatcht, aber das Grundproblem im Protokoll bleibt.

Anthropics Antwort: "By design"

Das wirklich Brisante an der Geschichte ist nicht die Lücke, sondern die Reaktion. Anthropic hat die Befunde bestätigt und eine Protokoll-Änderung abgelehnt. Die STDIO-Execution sei ein "sicherer Default", die Sanitization der Eingaben liege in der Verantwortung der Entwickler. Neun Tage nach der initialen Meldung hat Anthropic die SECURITY.md-Datei aktualisiert und einen Warnhinweis hinzugefügt: "STDIO adapters should be used with caution."

OX kommentiert trocken: "This change didn't fix anything."

Jake Moore, Global Cybersecurity Advisor bei ESET, nennt in SecurityWeek den Kern: Wer einen KI-Standard baut, der Performance über Kontrolle stellt, baut sich strukturelle Probleme ein, die später nicht mehr mit einem Patch auflösbar sind. Und OX setzt noch einen drauf: "Developers are not security engineers." Es sei unrealistisch zu erwarten, dass Zehntausende Implementierer unabhängig voneinander die Sicherheitsfallen in den offiziellen SDKs erkennen und entschärfen.

Das Supply-Chain-Problem für DACH-Teams

Der Supply-Chain-Angriff hat drei Dimensionen, die für Teams im deutschsprachigen Raum besonders relevant sind.

Erstens: Compliance. Eine RCE-Lücke mit potenziellem Datenabfluss berührt Artikel 33 und 34 der DSGVO direkt. Bei erfolgreicher Ausnutzung drohen nicht nur Datenabfluss, sondern auch Meldepflichten gegenüber den Aufsichtsbehörden binnen 72 Stunden. "Der Hersteller sagt, das ist by design" wird als Rechtfertigung für mangelnde Vorsorge schwer zu verkaufen sein.

Zweitens: Teams in der MCP-Einführung. Viele DACH-Teams sitzen gerade in der Pilot- oder Einführungsphase. MCP-Integrationen in CI-Pipelines, interne Wissensdatenbanken und Ticket-Systeme sind in den letzten Monaten in Mode gekommen. Wer jetzt pilotiert, muss die Due-Diligence nachholen. Ein MCP-Server, der von außen erreichbar ist und User-Input an StdioServerParameters durchreicht, ist ein offenes Scheunentor.

Drittens: Enterprise-Procurement. Sicherheitsverantwortliche, die MCP-basierte Tools für den Konzerneinsatz freigeben sollen, bekommen jetzt ein hartes Argument gegen Pro- und Team-Versionen ohne Härtung. Die souveräne-KI-Debatte, die Aleph Alpha und Cohere angestoßen haben, bekommt damit einen weiteren Pfeil im Köcher.

Was Teams jetzt tun sollten

OX Security und andere Experten nennen mehrere konkrete Mitigations, die Teams sofort umsetzen können. Anthropic liefert sie nicht, aber die Community hat Antworten.

User-Input niemals direkt an StdioServerParameters durchreichen. Wenn Input aus Chat, Formular oder API den MCP-Server erreicht, muss zwischen Input und Execute eine Allowlist stehen. Nur vordefinierte Befehle zulassen, alles andere blocken.
MCP-Server nur aus verifizierten Quellen installieren. Das offizielle GitHub MCP Registry ist die erste Wahl. Von unbekannten NPM-Paketen oder PyPI-Downloads Finger weg, Typosquatting ist auch bei MCP-Servern ein reales Risiko.
MCP-Dienste in Sandboxes einsperren. Die Docker-Sandbox-Lösung, die wir Anfang April besprochen haben, passt exakt zu diesem Use Case. MicroVM oder Container, keine Full-Disk-Rechte, keine Shell-Execution-Privilegien außer für die eine Funktion, die der Server wirklich braucht.
Lokale Bindings absichern. 127.0.0.1 als Bind-Adresse, niemals 0.0.0.0. Letzteres exponiert den Server ins gesamte Netzwerk und öffnet die Tür für DNS-Rebinding-Angriffe über den Browser.
Secrets prüfen. API-Keys, Chat-Historien und interne Datenbank-Zugänge, die in der Reichweite des MCP-Servers liegen, gehören in ein Rotationsverfahren. Wer sich nicht sicher ist, ob ein Angriff schon stattgefunden hat, rotiert jetzt.

Der saubere Fix wäre eine Protokoll-Änderung. Manifest-only-Execution oder eine Command-Allowlist auf SDK-Ebene würde das Problem im gesamten Ökosystem lösen. Solange Anthropic das ablehnt, müssen Teams selbst absichern.

Einordnung

MCP ist der de-facto-Standard für Agent-Tool-Kommunikation geworden. Die Geschwindigkeit, mit der das passiert ist, hat die Sicherheitspraxis abgehängt. Das erinnert an das Log4j-Muster von Ende 2021: Eine Bibliothek mit massiver Verbreitung, ein Architektur-Fehler, der niemandem aufgefallen ist, weil "wie kann das denn sein". Der Unterschied: Bei Log4j gab es innerhalb von Tagen einen Patch. Bei MCP sagt der Hersteller, der Fehler sei keiner.

Für Anthropic ist das ein schwieriger Moment. Die Firma kämpft ohnehin mit der Nerfing-Debatte um Claude, positioniert sich mit Managed Agents und Claude Design aggressiv im Markt, und muss gleichzeitig den Spagat zwischen Offenheit ("MCP ist ein offener Standard") und Verantwortung ("das ist dein Problem, Entwickler") hinbekommen. Die Antwort "by design" funktioniert im Developer-Kontext oft. Im Enterprise-Kontext selten.

Für dich als IT-Profi im DACH-Raum ist die Lage pragmatisch: MCP ist zu nützlich, um es ad acta zu legen, und gleichzeitig zu gefährlich, um es naiv zu betreiben. Die nächsten Wochen werden zeigen, ob Anthropic doch noch einlenkt, oder ob Sandboxing und Input-Validation der neue Standard-Workflow werden. Bis dahin gilt: Wer MCP produktiv nutzt, sollte heute noch einmal die eigene Konfiguration anschauen.