MCP-Server in der Breite ausführbar: Was die Anthropic-SDK-Kette für KI-Agenten im Mittelstand bedeutet

TL;DR — die 90-Sekunden-Zusammenfassung

Betroffen?

Jeder lokal startende MCP-Server (STDIO-Transport), der über eine clientseitige Config-Datei aufgerufen wird — Claude Desktop, Cursor, Continue, Roo Code, eigene MCP-Clients. ~200.000 Installationen weltweit.

Risiko?

Wer den Config-Pfad oder den Command-Pfad des MCP-Servers ändern kann, kontrolliert den Subprozess beim nächsten Client-Start. Direkter Code-Execution-Pfad als der startende User — typisch der Entwickler-Account.

Sofortmaßnahme?

Config-Datei-Berechtigungen prüfen (~/.config/claude/claude_desktop_config.json und Ähnliches), MCP-Server-Pfade auf absolute, fest-gepinnte Binärpfade, Subprozess-Sandboxing wo möglich (bwrap, firejail, container).

Empfehlung?

Mittelstand mit MCP-Stack: Config-Audit + Pfad-Pinning. Enterprise: zusätzlich Code-Signing-Verifikation der MCP-Server-Binärdateien plus Subprozess-Isolation.

Kritikalität?

Hoch (siehe Badge im Seitenkopf).

 

Was ist das Problem?

Das Model Context Protocol ist Anthropics standardisierter Weg, KI-Agenten an externe Datenquellen und Tools anzuschließen. Ein MCP-Server stellt einer KI-Anwendung — Claude Desktop, Cursor, Continue, eigene Clients — strukturierten Zugriff auf Dateien, Datenbanken, APIs oder System-Befehle bereit. Es gibt drei Transport-Varianten: STDIO, SSE und HTTP-Streamable.

Der STDIO-Transport ist der geläufigste Default. Der Client liest eine Konfigurationsdatei (typisch ~/.config/claude/claude_desktop_config.json bei Claude Desktop), findet darin pro MCP-Server einen command-Pfad und Argumente — und startet den Server als lokalen Subprozess. Kommunikation läuft über stdin und stdout im JSON-RPC-Format.

Genau in dieser Architektur sitzt CVE-2026-30623: Wer den Config-Pfad oder den darin referenzierten Command-Pfad verändern kann, kontrolliert den Subprozess beim nächsten Client-Start. Es gibt keine kryptografische Verifikation der MCP-Server-Binär, keine Code-Signing-Prüfung, keine Subprozess-Sandbox-Default. Der Subprozess startet im Kontext des Client-Users — typisch der Entwickler-Account auf einer Workstation — mit allen Berechtigungen, die dieser User hat.

Anthropic stuft das Verhalten in der eigenen Disclosure als „expected“ ein: Das STDIO-Transport-Modell sieht vor, dass der Client den Server-Subprozess vertraut. Wer den Server installiert hat, ist verantwortlich dafür, was er ausführt. Aus Anthropics Perspektive ist das eine Architektur-Wahl, kein Bug. Das ist eine vertretbare Position — sie verschiebt aber die Verantwortung vollständig zum Betreiber.

Praktisch trifft das eine breite Welt: rund 200.000 MCP-Server-Installationen weltweit (laut Anthropic-Telemetrie aus dem Disclosure-Beitrag), darunter Tausende eigene und community-gepflegte Server, die Datei-, Datenbank-, GitHub-, JIRA-, Confluence- oder eigene API-Zugriffe an Claude Desktop und vergleichbare Clients ankoppeln. Praktisch jeder, der MCP heute produktiv nutzt, läuft über STDIO — SSE und HTTP-Streamable sind die Ausnahme.

Wer ist betroffen?

Die Reichweite folgt der MCP-Adoption — und die ist im letzten Halbjahr stark gewachsen. Drei Profile aus unserer Beratungspraxis sind heute akut:

Quer dazu: jede MCP-Installation mit npm- oder pip-basiertem Server. Die typische Installation läuft über npx -y @modelcontextprotocol/server-filesystem oder ähnlich — das ist ein dynamischer Pull aus der npm-Registry beim Client-Start, ohne Pin auf einen verifizierten Hash. Wer hier auf :latest sitzt, lädt bei jedem Start die aktuelle Version aus der Registry.

Mitigation und Sofortmaßnahmen

Die kurze Antwort: Config-Datei-Berechtigungen prüfen, MCP-Server-Pfade hart pinnen, Subprozess in Sandbox starten wo möglich. Vier Schritte:

Config-Datei-Berechtigungen prüfen

# Welche User können die Claude-Desktop-Config schreiben?
stat -c '%U %G %a' ~/.config/claude/claude_desktop_config.json
stat -c '%U %G %a' ~/Library/Application\ Support/Claude/claude_desktop_config.json  # macOS

# Soll: nur der User selbst, 0600
chmod 0600 ~/.config/claude/claude_desktop_config.json

MCP-Server-Pfade hart pinnen

// ANSTATT: dynamischer npx-Pull bei jedem Start
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me"]
    }
  }
}

// BESSER: absolute Pfade, gepinnte Version, Hash-Verifikation im Update-Pfad
{
  "mcpServers": {
    "filesystem": {
      "command": "/usr/local/bin/mcp-server-filesystem",
      "args": ["/Users/me"]
    }
  }
}

Subprozess-Sandbox auf Linux

# MCP-Server in bwrap-Sandbox starten
{
  "mcpServers": {
    "filesystem": {
      "command": "bwrap",
      "args": [
        "--ro-bind", "/usr", "/usr",
        "--ro-bind", "/etc/ssl", "/etc/ssl",
        "--bind", "/Users/me/Documents", "/data",
        "--proc", "/proc",
        "--dev", "/dev",
        "--unshare-net",
        "--die-with-parent",
        "/usr/local/bin/mcp-server-filesystem", "/data"
      ]
    }
  }
}

Code-Signing-Verifikation im Update-Pfad

# Eigener MCP-Server: Signatur prüfen vor Verteilung
cosign verify-blob \
  --key cosign.pub \
  --signature mcp-server.sig \
  /usr/local/bin/mcp-server-internal

# CI/CD-Pipeline: nur sign-verifizierte Binärdateien in den Update-Stream lassen

Was „Claude soll das schon richten“ nicht löst. Anthropic hat die Position klar gesagt: das STDIO-Transport-Modell ist „as designed“. Es gibt keinen Patch, der die Subprozess-Vertrauensfrage für Sie löst — die liegt strukturell beim Betreiber.

Detection und Prüfung

Fünf Kernfragen, wenn MCP in Ihrem Stack läuft:

• Welche MCP-Server sind konfiguriert? Config-Datei lesen, alle mcpServers-Einträge auflisten.
• Werden absolute Pfade oder dynamische Loader (npx, uvx) verwendet? Dynamisch = Supply-Chain-Risiko bei jedem Start.
• Wer kann die Config-Datei schreiben? Andere User, andere Prozesse, Git-Hooks?
• Laufen die Subprozesse mit Sandbox oder direkt? Direkt = Code-Execution mit User-Privilegien.
• Welche Tokens sind im User-Account zugänglich? GitHub, AWS, Azure, GitLab — alles, was der User hat, kann der Subprozess holen.

# MCP-Server-Konfigurationen finden
for f in \
  ~/.config/claude/claude_desktop_config.json \
  ~/Library/Application\ Support/Claude/claude_desktop_config.json \
  ~/.cursor/mcp.json \
  ~/.continue/config.json; do
  [ -f "$f" ] && echo "=== $f ===" && jq -r '.mcpServers // .mcp.servers // {}' "$f"
done

# Prüfen, welche Binärdateien tatsächlich starten
lsof -c claude 2>/dev/null | grep -E '(node|python|deno)' | head

Betreiberempfehlung

Die Empfehlung hängt vom Setup ab. Vier Szenarien, vier Antworten — mit einem operativen Entscheidungsraster vorab:

Entscheidungsraster: Wann jetzt härten, wann Wartungsfenster?

• Sofort härten, wenn die Config-Datei in einem Git-Repo liegt, das mehrere Personen schreiben können, oder wenn dynamische Loader (npx -y, uvx) genutzt werden.
• Wartungsfenster möglich, wenn die Config-Datei nur lokal liegt und alle MCP-Server-Pfade auf absolute, gepinnte Binärdateien zeigen.
• Token-Scope reduzieren, wenn der User-Account weitreichende Cloud-Tokens hält (AWS-Admin, GitHub-Owner). Ein kompromittierter MCP-Subprozess sieht alles.
• CI/CD-Pipeline mit MCP? Sofort isolieren. CI-Runner sollten keinen Claude-Desktop-Workflow tragen.

Entwickler-Workstation mit Claude Desktop / Cursor

Config-Datei 0600, alle MCP-Server-Pfade auf absolute Binärdateien gepinnt, dynamische npx -y-Loader durch installierte Versionen ersetzen. Optional: bwrap-Sandbox auf Linux für nicht vertraute Server.

Team-Setup mit shared MCP-Konfiguration

Config nicht in einem Git-Repo halten, das jeder ungefiltert schreiben kann. Wenn unbedingt im Repo: Code-Review-Pflicht für Config-PRs, Pre-Commit-Hook gegen unerwartete command-Pfadänderungen, signierte Commits.

Mittelstand mit eigenem MCP-Server-Stack

Code-Signing der MCP-Server-Binärdateien per cosign oder sigstore. Update-Pfad mit Hash-Verifikation, nicht via direktem npm-Pull. SBOM über alle MCP-Server, die in der Mandanten-Distribution stecken.

Deklarative Stacks (NixOS-Workstations, Talos-Bots)

Die Sicht-Antwort: MCP-Server gehen über die Nix-Store-Pfade, sind kryptografisch hash-verifiziert, der command-Pfad ist deterministisch im Store. Wer NixOS für seine Entwickler-Workstations einsetzt, hat hier strukturellen Vorteil — nicht alle CVE-Klassen, aber genau diese.

Was wir konkret getan haben

Bei der Anthropic-Disclosure haben wir den eigenen MCP-Stack und den unserer Mandanten in einer zwei-stündigen Welle durchgeprüft. Pattern wie bei Comment-and-Control: SBOM über alle MCP-Konfigurationen, dann konkrete Schritte pro Stack.

• MCP-Konfig-Inventur. Alle Entwickler-Workstations und CI-Runner gescannt nach claude_desktop_config.json, cursor/mcp.json, .continue/config.json. 23 Workstations mit aktivem MCP, davon 14 mit dynamischen npx -y-Loadern.
• Config-Datei-Permissions. Auf zwei Workstations waren die Configs weltlesbar (0644). Auf 0600 gesetzt.
• Pfad-Pinning. Die 14 Workstations mit npx -y auf absolute, installierte Binärpfade umgestellt. Versionen über npm install -g mit Lockfile-Pin verteilt.
• Eigener MCP-Server-Stack. Wir betreiben einen eigenen, offen entwickelten MCP-Server (nicht proprietär, Open-Source). Hier haben wir Code-Signing per cosign eingeführt, Sigstore-Bundles bei jedem Release, Hash-Pin im Update-Pfad.
• Token-Scope-Review. Auf vier Workstations waren GitHub-Owner-Rechte und AWS-Admin-Rollen im User-Account aktiv. Diese auf eng skopierte Service-Tokens reduziert, MCP-Server bekommt eigene Identität mit minimalem Scope.
• Was wir bewusst nicht gemacht haben. MCP nicht aus dem Workflow entfernt — der Produktivitätswert ist real, das Modell ist verteidigbar. Kein Wechsel auf SSE oder HTTP-Streamable als reine „Sicherheit-durch-Transportwechsel“-Lösung; die Subprozess-Vertrauensfrage bleibt strukturell.

Diese Routine ist die operative Praxis aus DevSecOps as a Service und der Externen IT-Abteilung. Methodisch hängt MCP-STDIO im selben Geflecht wie Comment-and-Control und Semantic Kernel: KI-Agenten-Architektur ist eine Workflow- und Vertrauensgrenz-Frage, keine Modell-Frage.

Technischer Deep Dive

Das STDIO-Transport-Modell von MCP ist konzeptionell ein klassisches Unix-Subprozess-Pattern: der Client startet einen Server-Prozess, kommuniziert über stdin und stdout, beendet den Prozess beim Schließen. Drei strukturelle Aspekte sind entscheidend für das Verständnis von CVE-2026-30623:

Client-getriebener Subprozess-Start

Beim Start liest der Client (Claude Desktop, Cursor, Continue) seine Konfigurationsdatei. Die enthält pro MCP-Server einen command-Pfad und Argumente. Der Client ruft exec() auf diesen Pfad auf, im Kontext des Client-Users. Es gibt keine kryptografische Verifikation der Binär, keine Sandbox-Default, keine Policy-Engine. Wer den command-Pfad in der Config setzt, bestimmt, was startet.

Dynamischer Loader-Pfad

Die typische MCP-Installation nutzt npx -y @modelcontextprotocol/server-foo oder uvx mcp-server-foo als command. Diese Löser pullen bei jedem Start die aktuelle Version aus der npm- oder PyPI-Registry. Es gibt im Default keinen Hash-Pin, keine Versions-Lock, keine Supply-Chain-Verifikation. Ein npm-Account-Übernahme oder eine kompromittierte PyPI-Distribution kompromittiert den nächsten Client-Start direkt.

JSON-RPC-Frame und Tool-Capability

Im JSON-RPC-Datenstrom über stdin/stdout sendet der Client tools/list- und tools/call-Requests. Der Server antwortet mit Tool-Capability-Beschreibungen und führt aufgerufene Tools aus. Das Modell kann über den Client jeden Tool-Aufruf triggern, den der Server anbietet. Wenn der Server kompromittiert ist, sind die Tools kompromittiert — mit User-Rechten.

Aspekte für die Bewertung

• Vertrauensmodell ist „bewusst flach“. Anthropic-Position: das STDIO-Modell vertraut dem Server. Wer den Server installiert, ist verantwortlich. Das ist konsistent mit dem Unix-Subprozess-Pattern — ungewohnt für die Web-Security-Welt.
• Config-Datei ist das eigentliche Angriffsziel. Wer schreiben kann, kontrolliert den nächsten Start. 0600-Permissions, signierte Commits, Pre-Commit-Hooks gegen unerwartete Pfadänderungen.
• Dynamische Loader sind die Supply-Chain-Brücke.npx -y ohne Pin ist ein :latest-Pull bei jedem Start.
• NixOS und deklarative Stacks profitieren strukturell. Nix-Store-Pfade sind kryptografisch hash-verifiziert, deterministisch, unveränderlich. Wer den command-Pfad auf einen Nix-Store-Pfad setzt, hat den Subprozess-Start kryptografisch fest gemacht.

Fazit

CVE-2026-30623 ist keine Software-Lücke im klassischen Sinn — es ist eine Architektur-Wahl, die Anthropic offen als „expected“ stehen lässt. Das STDIO-Transport-Modell vertraut dem Server-Subprozess, und der Client startet ihn mit User-Rechten. Wer das System produktiv nutzt, trägt die Subprozess-Vertrauensfrage strukturell selbst.

Operativ wichtiger als die Einzel-CVE ist das Muster dahinter: jede MCP-Konfiguration mit dynamischem Loader und schreibbarer Config-Datei ist ein potenzieller Subprozess-C2-Kanal. Wer Config-Permissions auf 0600, Pfad-Pinning auf absolute Binärpfade und Code-Signing im Update-Pfad konsequent durchgezogen hat, beantwortet die nächste vergleichbare Disclosure in Stunden, nicht in einer Subprozess-Forensik.

Realistische Risiko-Einordnung: Hoch für Workstations mit Cloud-Admin-Tokens und dynamischen MCP-Loadern. Mittel für Mittelstand-Stacks mit gepinnter Konfiguration. Niedrig für deklarative Setups (NixOS, Talos), die Subprozess-Pfade kryptografisch absichern. Die Frage lautet nicht, wann der nächste vergleichbare MCP-Befund kommt. Sie lautet, ob Sie ihn auf einer Konfiguration erleben, in der jeder Subprozess-Start nachvollziehbar und kryptografisch gepinnt ist — oder auf einer, in der ein npm-Account-Übernahme reicht, um den nächsten Client-Start zu kompromittieren.