MCP-Sicherheit: Warum 200.000 verwundbare Instanzen geregelte Module zu einem Kaufkriterium machen

Die Offenlegung

Im April und Mai 2026 legte OX Security einen systemischen Architekturfehler in Model Context Protocol-STDIO-Konfigurationen offen, der Kommandoinjektion und Remote-Code-Ausführung ermöglicht. Das Advisory deckt 10 CVEs über die MCP-Lieferkette ab — schätzungsweise 200.000 verwundbare Instanzen, die 150 Millionen Downloads berühren. Die Schwachstelle befindet sich nicht in einem einzelnen Paket. Sie liegt im Standard-Konfigurationsmuster, mit dem die meisten Community-MCP-Server ausgeliefert werden.

Die Cloud Security Alliance titelte ihren Research-Hinweis „MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure". OWASP startete ein MCP Top 10-Projekt, um die kritischsten Sicherheitsbedenken über den Lebenszyklus MCP-fähiger Systeme hinweg zu katalogisieren. Aembit veröffentlichte einen Leitfaden, der Transportrisiken und Lieferketten-Bedrohungen abdeckt. TrueFoundry veröffentlichte einen Enterprise-Leitfaden zu MCP-Sicherheitsrisiken und Best Practices.

Das Muster bei allen: die Angriffsfläche existiert, weil Community-MCP-Server ohne die Governance-Schicht gebaut und eingesetzt werden, die Produktionssysteme erfordern.

Was die Schwachstelle tatsächlich ist

MCP-Server kommunizieren mit KI-Agenten-Clients über einen Transport. Der STDIO-Transport — der Standard für lokale Entwicklung und viele Produktions-Deployments — übergibt Nachrichten über Standard-Eingabe und -Ausgabe. Die OX-Security-Offenlegung identifizierte, dass gängige STDIO-Konfigurationsmuster Kommandoinjektion erlauben: eine präparierte Eingabe kann beliebige Befehle auf dem Host ausführen, der den MCP-Server betreibt.

Dies ist kein theoretischer Angriffspfad. MCP-Server laufen auf derselben Maschine wie der Agenten-Client, mit denselben Prozessberechtigungen. Ein Server, der Shell-Befehle auf Basis von Eingaben akzeptiert und ausführt, die er über STDIO empfängt, ist per Konstruktion eine Remote-Code-Ausführungsfläche. Die Schätzung von 200.000 Instanzen spiegelt das Ausmaß der Community-MCP-Adoption wider — Server, die in Registern veröffentlicht, aus Repositories geklont und mit Standardkonfigurationen deployt wurden, die nie für die Produktion gehärtet wurden.

Backslash Security identifizierte separat drei neue Angriffsflächen, die der MCP-2026-07-28-Release-Candidate selbst einführt — dieselbe Spezifikation, die in 20 Tagen finalisiert wird. Neue Fähigkeiten (serverseitig gerenderte UIs, langlaufende Tasks, header-basiertes Routing) schaffen neue Einstiegspunkte, die die Sicherheits-Community noch kartiert.

Die Breach-Chronologie von 2026

Die Offenlegung von OX Security war kein Einzelereignis. Sie fügt sich in eine Breach-Chronologie ein, die sich im ersten Halbjahr 2026 ausweitete, und es sind die benannten Schwachstellen, die aus „Governance ist gute Praxis" ein „Governance ist ein Kaufkriterium" machen.

Vier neue CVEs traten 2026 auf: CVE-2026-33032 („MCPwn", CVSS 9.8, >2.600 exponierte Instanzen), CVE-2026-0755 (Gemini-MCP-Tool, CVSS 9.8), CVE-2026-35394 (Mobile MCP RCE, April 2026, Android Intent Injection, CWE-939) und ein gefälschter Oura-MCP-Trojaner im Februar 2026, der die StealC-Malware verbreitete. Practical DevSecOps stellte fest, dass 30–82 % der öffentlichen MCP-Server ausnutzbare Fehler aufweisen und nur 8,5 % OAuth zur Authentifizierung verwenden.

Das Gesamtbild ist düsterer: 47–53 % der Organisationen meldeten im vergangenen Jahr agentenbezogene Sicherheitsvorfälle, und nur 14,4 % der KI-Agenten erreichen die Produktion mit voller Sicherheitsgenehmigung. Die Lücke zwischen Adoption und Governance ist der Ort, an dem die MCP-Sicherheitskrise existiert.

Client-seitige OAuth-RCE — eine neue Angriffsklasse

Die obigen CVEs sind serverseitige Schwachstellen — der MCP-Server ist das Ziel. Im September 2025 legte Obsidian Security eine völlig andere Angriffsklasse offen, die den Client-Host ins Visier nimmt. Der OAuth-Discovery-Flow der MCP-Authorization-Spezifikation öffnet eine Hintertür: Desktop- und CLI-MCP-Clients, die für OAuth einen Browser starten, ohne URLs zu bereinigen, sind anfällig für OS-Kommandoinjektion und Remote-Code-Ausführung. Ein bösartiger Remote-MCP-Server kann die Client-Maschine kompromittieren.

Vier CVEs wurden vergeben, darunter CVE-2025-54074, der Cherry Studio betrifft. Die betroffenen Clients überspannen das Ökosystem: Cherry Studio, Gemini-CLI, MCP Inspector, VS Code, Windsurf, Smithery.ai, Lutra.ai und Glue.ai. Für den Angriff ist kein verwundbarer Server erforderlich — er benötigt einen verwundbaren Client, der sich mit einem beliebigen Server verbindet, den der Angreifer kontrolliert.

Diese Klasse unterscheidet sich von den serverseitigen Lieferketten-Angriffen, weil die Gegenmaßnahme auf einer anderen Schicht liegt. Serverseitige Härtung (Audit-Logs, Ratenbegrenzungen, typisierte Fehler, Kill-Switch) schützt den Client-Host nicht. Der Client muss OAuth-Redirect-URLs bereinigen und das Discovery-Dokument validieren, bevor er einen Browser startet. Das Framework, das den Browser startet, muss einschränken, welche URLs es öffnet.

BlueRock Security stellte fest, dass 36,7 % von über 7.000 gescannten MCP-Servern anfällig für Server-Side Request Forgery (SSRF) sind — ein Angriff, der es einem kompromittierten MCP-Server ermöglicht, beliebige ausgehende Anfragen vom Host auszuführen, auf dem er läuft. Kombiniert mit den clientseitigen Erkenntnissen von Obsidian überspannt die Angriffsfläche nun beide Enden der Verbindung: der Server kann den Client angreifen (OAuth-RCE), und der Server kann das Netzwerk angreifen, auf dem er läuft (SSRF).

Zwei weitere CVEs erweitern die Chronologie um neue Angriffsklassen:

• CVE-2026-39313 — mcp-framework HTTP-Server-Denial-of-Service. Speichererschöpfung durch präparierte Anfragen an die HTTP-Transportschicht. Dies ist die erste dokumentierte DoS-Attacke gegen den MCP-HTTP-Transport, keine RCE — eine neue Schwachstellenkategorie.
• CVE-2026-33224 — Bisheng authentifizierte Remote-Kommandoausführung innerhalb der MCP-Werkzeugkonfiguration. Dies erweitert das STDIO-Lieferketten-Advisory auf ein neues betroffenes Produkt und bestätigt, dass die Angriffsfläche auf Konfigurationsebene nicht auf die ursprüngliche OX-Security-Offenlegung beschränkt ist.
• CVE-2026-27826 — MCP Atlassian SSRF (CVSS 8.2, sooperset:mcp-atlassian Versionen < 0.17.0). Diese Schwachstelle ist dadurch einzigartig, dass sie unauthentifiziert ist und in der HTTP-Middleware- und Dependency-Injection-Schicht liegt, nicht in einem MCP-Tool-Handler. Sicherheitsüberprüfungen, die sich nur auf Tool-Handler konzentrieren, übersehen die HTTP-Transportschicht vollständig. In Cloud-Deployments ermöglicht der SSRF den Diebstahl von IAM-Rollen-Anmeldedaten über den Instanz-Metadaten-Endpunkt (169.254.169.254). Die Middleware-nicht-Tool-Handler-Position ist eine eigenständige Angriffsfläche, die Tool-Level-Code-Analyse nicht erkennen kann.

Reddit's r/AI_Agents-Community berichtete, dass innerhalb von 60 Tagen (Januar–März 2026) 30 CVEs gegen MCP-Server eingereicht wurden, mit über 12.000 exponierten Instanzen. Practical DevSecOps bestätigte, dass 13 dieser 30 CVEs (etwa 43 %) Kommandoausführungs-Schwachstellen sind. Die Geschwindigkeit beschleunigt sich, sie stabilisiert sich nicht.

Die Governance-Schicht — Audit-Logs, Ratenbegrenzungen, typisierte Fehler, Kill-Switch-Architektur, PII-Grenzen — adressiert die serverseitige Angriffsfläche. Die clientseitige OAuth-RCE-Klasse erfordert clientseitige URL-Bereinigung, eine separate Gegenmaßnahme, die die MCP-Spezifikation und die Client-Frameworks noch aktualisieren, um sie durchzusetzen. Beide Schichten sind nötig.

Warum Community-Server die Schwachstelle sind

Die meisten Community-MCP-Server werden gebaut, um eine Fähigkeit zu demonstrieren — einen Agenten mit einem Werkzeug verbinden, ein Ergebnis zurückgeben. Sie sind nicht für den Betrieb gebaut. Die Governance-Kontrollen, die Produktionssysteme erfordern, fehlen standardmäßig:

• Kein Audit-Logging. Werkzeugaufrufe werden nicht mit Anfrage, Antwort, Latenz und Ergebnis protokolliert. Wenn ein Vorfall auftritt, gibt es keinen Trail zur Rekonstruktion.
• Keine Ratenbegrenzung. Ein Werkzeug kann unbegrenzt aufgerufen werden. Ein kompromittierter oder fehlverhaltender Agent kann Upstream-API-Kontingente erschöpfen oder unerwünschte Nebeneffekte im großen Maßstab auslösen.
• Kein typisierter Fehlervertrag. Fehler werden als Strings oder unstrukturierte Antworten zurückgegeben. Der Agent kann einen vorübergehenden Fehler nicht von einem dauerhaften unterscheiden, und der Betreiber kann Vorfälle nicht programmgesteuert klassifizieren.
• Kein Kill-Switch. Es gibt kein Operator-Runbook, keinen Fallback-Pfad, keine Möglichkeit, ein Modul zu deaktivieren, ohne den Orchestrierungs-Backbone anzufassen.
• Keine Testabdeckung. Fehlerpfade sind ungetestet. Ein Fehlermodus, das in der Entwicklung nie ausgeübt wurde, ist dasjenige, das in der Produktion ausgelöst wird.

Dies sind keine exotischen Sicherheitsanforderungen. Es sind dieselben Kontrollen, die jede Produktions-API durchsetzt. Die Lücke besteht darin, dass MCP-Server deployt werden, als seien sie Entwicklungswerkzeuge, nicht Produktionsintegrationen.

Wie geregelte Module aussehen

Der MCP-Modul-Codestandard, den wir veröffentlichen, definiert die Governance-Schicht, die jede dieser Lücken adressiert. Der Standard ist kein Sicherheits-Framework — er ist ein Codestandard, der Sicherheit durchsetzbar macht. Die Kontrollen sind konkret:

Audit-Logging. Jeder Werkzeugaufruf protokolliert Zeitstempel, Agent-ID, Werkzeugname, Eingabe-Hash (nicht die rohe Eingabe — PII-Grenze), Ausgabestatus, Dauer und Upstream-System. Logs sind strukturiertes JSON, das an die Observability-Pipeline gesendet wird. Wenn ein Vorfall auftritt, rekonstruiert der Audit-Trail den vollständigen Workflow-Zustand aus Anfrageargumenten und Handles — keine Korrelation mit Session-Store-Logs erforderlich.

Ratenbegrenzung. Jedes Werkzeug deklariert seine eigene Ratenbegrenzung im Registrierungsaufruf. Der Backbone setzt Limits pro Agent, pro Werkzeug und pro Zeitfenster durch. Wenn ein Limit erreicht wird, erhält der Agent eine 429-Antwort mit einem Retry-After-Header — er stürzt nicht ab und wiederholt nicht blind. Ein kompromittierter Agent kann Upstream-Kontingente nicht erschöpfen, weil das Ratenlimit an der Modulgrenze durchgesetzt wird, nicht an der Upstream-API.

Typisierter Fehlervertrag. Module lösen typisierte Exceptions aus — MCPAuthError, MCPRateLimitError, MCPTimeoutError, MCPValidationError, MCPUpstreamError — keine bloßen Strings. Der Backbone fängt diese ab und wandelt sie in strukturierte Antworten um, über die der Agent räsonieren kann. Ein Betreiber kann Vorfälle programmgesteuert klassifizieren, weil jeder Fehler einen Code trägt.

Behandlung der PII-Grenze. Module deklarieren, welche Eingabefelder PII enthalten. Der Backbone hasht diese Felder (SHA-256) vor dem Protokollieren und sendet niemals rohe PII an die Audit-Pipeline. Der Werkzeug-Handler erhält weiterhin den rohen Wert — die PII-Behandlung wird an der Logging-Grenze durchgesetzt, nicht innerhalb der Geschäftslogik.

Testabdeckung. Jedes Werkzeug hat Anfrage-/Antwort-Tests und Fehlerpfad-Abdeckung. Integrationstests laufen gegen Sandbox-Umgebungen. Mock-Tests verifizieren Werkzeugregistrierung, Argument-Mapping, Antwort-Normalisierung, Fehler-Propagation und Statusübergänge. Ein Fehlermodus, das in der Entwicklung nie ausgeübt wurde, wird nicht ausgeliefert.

Der 38-Werkzeug-Beweispunkt

Diese Kontrollen sind nicht aspirativ. Sie sind die Struktur des mcp_hospirfq_processor — eines Moduls, das 38 Werkzeuge über den kompletten RFQ-Lebenszyklus registriert: Anfrageerstellung, Katalogsuche, Angeboterstellung, Preisstufen, Verfügbarkeitsreservierungen, Stornierungsrichtlinien, Bundle-Entdeckung und Auftragsübergabe.

Der Fehler-Handler des Moduls definiert typisierte Fehlercodes für jedes Fehlermodus — GRAPHQL_QUERY_FAILED, VALIDATION_FAILED, HOLD_NOT_FOUND, HOLD_ALREADY_EXPIRED, AVAILABILITY_INSUFFICIENT, PRICING_MODE_UNSUPPORTED. Jeder Fehler trägt einen Code und strukturierte Details. Der handle_errors-Dekorator umhüllt jede Werkzeugmethode, sodass kein Werkzeug eine unstrukturierte Exception zurückgibt. Der Status-Manager setzt gültige Zustandsübergänge durch — eine Reservierung kann bestätigt, freigegeben oder abgelaufen sein, aber nicht von initial direkt zu completed springen.

So sieht ein geregeltes Modul in der Praxis aus: jedes Werkzeug hat ein Schema, jeder Fehler hat einen Code, jeder Aufruf hat ein Log, jeder Zustandsübergang hat einen Validator. Die Governance liegt im Code, nicht in einem Dokument, das jemand vielleicht liest.

Die Kill-Switch-Architektur

Die Governance-Schicht erstreckt sich über das Modul hinaus in den Orchestrierungs-Backbone. Das Engineering-Brief spezifiziert die operative Haltung:

• Operator-Runbook. Deployment, Rollback, Incident-Response und gängige Operationen sind dokumentiert. Wenn sich ein Modul fehlerverhält, folgt der Operator einem Runbook, nicht einem Slack-Thread.
• Fallback-Pfade. Graziöse Degradation, wenn ein Backend nicht verfügbar ist. Ein Modul, das sein Upstream-System nicht erreichen kann, gibt einen strukturierten Fehler zurück, und der Agent routet zu einem Fallback-Werkzeug oder eskaliert an einen Menschen.
• Feature-Flag-Rollout. Module werden pro Umgebung aktiviert. Ein Modul kann deaktiviert werden, ohne den Orchestrierungs-Backbone anzufassen — der Kill-Switch ist eine Konfigurationsänderung, kein Code-Deployment.
• Observability. Strukturierte Logs, Metriken und Traces werden an den Monitoring-Stack gesendet. Das Verhalten des Agenten ist end-to-end auditierbar — dieselbe Haltung, die Unternehmen auf Finanzkontrolle anwenden.

Die Kill-Switch-Architektur ist die Kontrolle, die die OX-Security-Offenlegung als fehlend in 200.000 Community-Servern aufzeigt. Wenn eine Schwachstelle offengelegt wird, lautet die erste Frage des Operators: Kann ich dieses Modul deaktivieren, ohne den Agenten stillzulegen? In einem geregelten Deployment lautet die Antwort ja. In einem Community-Server-Deployment lautet die Antwort meist nein — der Server ist in die Werkzeugliste des Agenten eingetragen, und das Entfernen erfordert Code-Bearbeitung und erneutes Deployment.

Warum dies jetzt ein Kaufkriterium ist

Die PwC 2026 Global CEO Survey (4.454 CEOs) ergab, dass 56 % der Organisationen keinen messbaren finanziellen Nutzen aus KI berichten. Die WRITER-Enterprise-KI-Adoptionsumfrage ergab, dass 35 % der Unternehmen einen KI-Agenten nach dem Deployment nicht abschalten können. Die Kombination ist das Kaufkriterium: ein System, das nicht deaktiviert werden kann, ist eine Verbindlichkeit, und ein System, das keinen messbaren Nutzen bringt, ist ein Kostenfaktor. Governance — Audit-Logs, Ratenbegrenzungen, typisierte Fehler, Kill-Switch-Architektur — ist die Kontrolle, die einen KI-Agenten sicher im Einsatz und sicher bei der Außerbetriebnahme macht.

Gartner sagt voraus, dass bis Ende 2026 Klagen wegen „Tod durch KI" 2.000 übersteigen werden aufgrund unzureichender KI-Risiko-Leitplanken. Der EU AI Act wird am 2. August 2026 voll anwendbar — 25 Tage ab heute. Die Transparenzregeln von Artikel 50 verlangen die Kennzeichnung KI-generierter Inhalte. Risikoklassifizierung, Dokumentation und Aufzeichnungspflichten werden für Hochrisikosysteme verbindlich. Die Audit-Logs und Operator-Runbooks, die geregelte Module bereits mitliefern, sind der Compliance-Nachweis, den der EU AI Act verlangen wird.

Die MCP-2026-07-28-Spezifikation wird in 20 Tagen finalisiert. Wenn sie erscheint, werden Such- und Zitationsvolumen für „Model Context Protocol" steigen — und ebenso die Prüfung der Angriffsfläche. Die Community-Server, die den Governance-Maßstab nicht erfüllen, werden diejenigen sein, die markiert werden.

Die Entscheidung

Wenn ein Team ein MCP-basiertes Agenten-Deployment evaluiert, lautet die Frage nicht mehr „verbindet es sich?". Community-Server verbinden sich. Die Frage lautet: wenn etwas schiefgeht, können Sie es sehen, stoppen und beweisen, was passiert ist?

Geregelte Module beantworten alle drei Fragen mit ja. Community-Server beantworten standardmäßig alle drei mit nein. Die 200.000 verwundbaren Instanzen sind der Beweis.

---

Ein Distributor, der NetSuite, BigCommerce und drei Lieferantenkataloge betreibt, erhält einen Agenten, der eine RFQ per E-Mail oder Portal empfängt, Produkte und Substitute gegen den Katalog-Graphen auflöst, Preise nach Kundensebene festlegt, Bestand mit einer Frist reserviert und das angenommene Angebot zurück nach NetSuite schreibt — mit jedem Schritt protokolliert, jedem Werkzeug ratenbegrenzt und jedem Modul per Konfiguration deaktivierbar. Dieser Build ist Phase 2-3 der Vier-Schritte-Methode und ist typischerweise in 5-8 Wochen live.

Angebot für ein abgegrenztes Build anfordern. Einwöchige Discovery. Sie erhalten ein Systeminventar, eine Workflow-Karte und einen festen Umfang — ob Sie mit uns bauen oder nicht.