MCP-STDIO-Sicherheit, was die OX-Security-Story für Dich bedeutet
Im April 2026 hat OX Security eine systemische RCE-Schwachstelle im MCP-STDIO-Transport veröffentlicht. 11 CVEs, 200K verwundbare Instanzen. Hier ist was Du als Operator und als Builder wirklich tun musst.
Am 15. April 2026 hat OX Security einen Blog-Post veröffentlicht der unter Sicherheitsforschern als "Mother of all AI Supply Chain Attacks" gehandelt wird. Sechs unabhängige Quellen haben die Befunde bestätigt, darunter The Hacker News, Infosecurity Magazine, SecurityWeek und Tom's Hardware. Anthropic hat die Schwachstelle als "expected behavior" eingeordnet, Sanitization sei Developer-Verantwortung. Das ist kein Zitat mit Schutzfunktion, das ist genau der Punkt der die Diskussion trägt.
Wenn Du diesen Playbook liest, hast Du wahrscheinlich gehört dass MCP-Server unsicher sind, und willst wissen ob Du jetzt etwas ändern musst. Die kurze Antwort lautet, als Konsument der MCP-Server installiert vermutlich nichts dramatisches, als Builder eines eigenen MCP-Servers schon.
Was OX Security gefunden hat
Der MCP-STDIO-Transport ist die Standard-Variante in der MCP-Server lokal als Subprozess gestartet werden. Anthropic-SDKs in Python, TypeScript, Java und Rust führen beim Server-Start OS-Commands aus und reichen Argumente weiter. OX hat gezeigt dass diese Argumente in vielen produktiven Server-Implementierungen direkt zu Shell-Aufrufen werden, und dass selbst best-practice-konforme Sanitization die Lücke nicht schließt.
Die Zahlen aus dem Original-Post: 150 Millionen monatliche SDK-Downloads, 7.000 öffentlich publizierte MCP-Server, geschätzt bis zu 200.000 verwundbare Instanzen. Mindestens 11 CVEs sind zugeordnet. Die Liste umfasst LiteLLM, LangChain-Chatchat, LangFlow (CVE-2026-40933), Flowise, Windsurf (CVE-2026-30615), Bisheng, Upsonic, DocsGPT, Agent Zero, Fay Framework und GPT Researcher. Das sind Frameworks die Tausende von Builds nutzen, kein Reddit-Hype.
Der wichtigste Befund ist nicht die Liste, sondern die OX-Followup-Analyse. Selbst Frameworks die explizit Sanitization eingebaut haben (Flowise CVE-2026-40933, Upsonic CVE-2026-30625) wurden umgangen. Python und Node erlauben über Argumente Shell-Tricks die mit naiver Whitelist-Validation nicht abgefangen werden. Das ist die Stelle an der Anthropic sagt "expected behavior".
Bist Du betroffen, drei klare Fälle
Fall 1, Du installierst MCP-Server in Claude Desktop oder Claude Code. Du bist Konsument. Risiko ist niedrig solange Du nur MCP-Server installierst die Du selbst kennst oder die aus vertrauenswürdigen Quellen kommen (offizielle Anthropic-Releases, etablierte OSS-Projekte, der StudioMeyer Marketplace). Wirklich gefährlich wird es wenn Du fremde MCP-Server aus Forks oder unbekannten Repos installierst, weil ein bösartiger Server beim Start beliebige Befehle auf Deinem System ausführen kann.
Konkrete Maßnahmen, die Du heute treffen solltest. Schau Dir Deine ~/.claude/settings.json an und liste die installierten MCP-Server. Für jeden der nicht von Dir oder einer offiziellen Quelle kommt, frag Dich ob Du den Anbieter wirklich kennst. Im Zweifel deinstallieren. Bei jedem neuen MCP-Server der nicht aus einer vertrauten Quelle kommt, lies die command:-Zeile. Wenn dort npx -y irgendwer/mcp-server steht, lädst Du fremden Code aus npm und führst ihn beim nächsten Claude-Start aus. Das ist die selbe Vertrauens-Frage wie bei npm-Packages, nicht mehr und nicht weniger.
Fall 2, Du baust einen MCP-Server für Dich oder Dein Team. Du bist Builder, das Risiko ist mittel. Wenn Dein Server keine Argumente von außen entgegennimmt, sondern nur fest verdrahtete Tools mit zod-validierten Input-Schemas anbietet, bist Du in Ordnung. Wenn Du aber irgendwo child_process.exec() oder shell=True aus einem Tool-Argument-String aufrufst, hast Du genau die Schwachstelle die OX gefunden hat. Pflicht-Fix, nutze execFile oder spawn mit Argument-Array statt exec, und validiere jeden Argument-String gegen eine strikte Allowlist statt eine Blocklist.
Fall 3, Du publizierst MCP-Server auf einem Marketplace oder Registry. Du bist Distributor, das Risiko ist hoch und es betrifft auch Deine Nutzer. Hier gilt zusätzlich, signierte Releases (npm provenance), klare Auth-Boundaries (kein Root-Zugriff auf Dateisystem ohne explizite User-Bestätigung), und ein dokumentiertes Sicherheits-Statement im README das beschreibt welche Argumente Dein Server akzeptiert und wie sie validiert werden.
Was Du heute prüfen kannst, fünf Minuten
Wenn Du einen eigenen MCP-Server hast, suche im Code nach drei Mustern.
Suche eins: Aufrufe von child_process.exec() mit interpolierten Argumenten. Pattern in TypeScript ist meistens ein Template-String wie some-cli ${userInput} direkt in exec(...). Jeder Treffer ist ein potenzielles Problem. Lösung ist execFile("some-cli", [userInput]) mit explizitem Argument-Array.
Suche zwei: Python subprocess.run() oder subprocess.Popen() mit shell=True. Standard-Empfehlung ist shell=False und Liste statt String. Wenn Du shell=True brauchst weil Du Pipes oder Redirects nutzt, eskapier die User-Inputs explizit mit shlex.quote().
Suche drei: Tool-Handler die Pfade entgegennehmen und an fs.readFile, fs.writeFile oder ähnliches geben. Pflicht ist eine Pfad-Validierung gegen Path-Traversal (..-Segmente, absolute Pfade die nicht in Deinem allowed-base-dir liegen, NUL-Bytes, Windows-Drive-Letters). In TypeScript ist path.resolve() plus ein startsWith(allowedBase) Check der Standard.
Das Anthropic-Statement und was es wirklich bedeutet
Anthropic hat in Reaktion auf die OX-Story klargestellt dass STDIO-Server den selben Sicherheits-Kontext haben wie die Anwendung die sie startet, und dass Sanitization in der Verantwortung des Server-Entwicklers liegt. Das ist technisch korrekt, aber unbefriedigend wenn Du als End-User MCP-Server aus einem Marketplace installierst und nicht den Source-Code prüfen kannst.
Die praktische Konsequenz, MCP-Server sind heute in der gleichen Vertrauens-Klasse wie npm-Packages, VSCode-Extensions oder beliebige CLI-Tools die Du installierst. Nur weil ein Server in einem Marketplace gelistet ist, heißt das nicht dass er auditiert wurde. Anthropic-Marketplaces machen kein Code-Review, das ist nicht ihre Rolle. Die Rolle die nicht besetzt ist, jemand der die Server vor Listing prüft, könnte mittelfristig von den großen Marketplaces oder von einer unabhängigen Stelle übernommen werden. Aktuell ist sie nicht besetzt.
Praxis-Empfehlung für Deinen Setup
Wenn Du heute mit MCP arbeitest, sortier Deine Server in drei Kategorien.
Kategorie eins, Anthropic-eigene Server (filesystem, fetch, sequential-thinking) und Deine eigenen. Trust-Level hoch.
Kategorie zwei, Server von etablierten OSS-Projekten mit aktiver Community und sichtbarem Maintainer (memory-server von StudioMeyer, GitHub MCP von github/github-mcp-server, sentry, postgres). Trust-Level mittel, lies das README, checke ob es Security-Statement und CI gibt.
Kategorie drei, alles andere. Trust-Level niedrig. Nicht installieren ohne Source-Code-Spotcheck.
Wenn Du einen eigenen Server baust, nimm Dir 30 Minuten und gehe die drei Suchen oben durch. Wenn Du was findest, fix es heute und teste mit einem absichtlich bösartigen Tool-Argument ("; ls -la" oder $(whoami)) ob der Server das ausführt oder zurückweist. Wenn der Server ausführt, hast Du genau das Pattern was OX beschreibt.
Was als nächstes
Wenn Du Deinen ersten MCP-Server bauen willst und das hier mit-bedenken willst, Playbook "erster-mcp-server-in-90-minuten" startet bei Null und macht die Sanitization von Anfang an richtig. Wenn Du publizieren willst, "mcp-server-publishen" deckt Distribution + Trust-Signale ab. Für DACH-Compliance-Aspekte (Auftragsverarbeitung, EU AI Act Klassifizierung), Playbook "dach-legal-eu-ai-act-und-dsgvo" hat einen frischen Block zur MCP-Security-Compliance.
Hauptquellen wenn Du tiefer einsteigen willst, der Original-OX-Post (ox.security/blog/the-mother-of-all-ai-supply-chains), die Followup-Analyse zu Flowise und Upsonic, plus die CVE-Eintragungen für CVE-2026-40933 (LangFlow) und CVE-2026-30615 (Windsurf) als konkrete Reproduktions-Beispiele.