TL;DR
MCP Tool Poisoning ist die akuteste Angriffsfläche für Agent-Pipelines: OX Security meldete im April 2026 CVE-2026-30623 mit CVSS 9.8 in den offiziellen Anthropic-SDKs, rund 200.000 Server gelten als verwundbar. Wer Claude, AutoGen oder LangGraph produktiv betreibt, braucht ab sofort Manifest-Hashing, Egress-Kontrolle und einen MCP-Inventar-Prozess unter NIS2 und DORA.
Was MCP Tool Poisoning konkret bedeutet
Das Model Context Protocol (MCP) ist seit Ende 2024 der De-facto-Standard, mit dem Sprachmodelle externe Tools, Datenbanken und APIs ansprechen. Anfang 2026 zählt die Glama-Registry 23.968 Server, MCP.so listet über 19.000 weitere. Die offiziellen Anthropic-SDKs werden monatlich 97 Millionen Mal heruntergeladen, kumulativ über 150 Millionen Mal. Diese Verbreitung trifft auf eine Sicherheitsarchitektur, die ursprünglich für lokale Entwickler-Setups gebaut wurde, nicht für Produktion.
Unter MCP Tool Poisoning fassen wir jede Manipulation zusammen, durch die ein MCP-Server dem aufrufenden Modell bösartige Instruktionen, Tool-Definitionen oder Ausgaben unterschiebt. Das Modell sieht eine vertraute Tool-Beschreibung, der Server tut etwas anderes. In unserer Erfahrung aus Audits bei Banken und Industriekunden ist das selten ein klassischer Exploit — es ist Vertrauensmissbrauch in einer Schnittstelle, die für Vertrauen designt wurde.
Drei Wochen alte Disclosures von OX Security zeigen, wie ernst die Lage ist: 9 von 11 großen MCP-Registries ließen sich mit einem Test-Payload poisonen. Trend Micro fand im Februar 2026 in einer Scan-Studie 492 MCP-Server mit Public-IP komplett ohne Authentifizierung; 38 Prozent von 500+ untersuchten Servern hatten gar keinen Auth-Layer.
Die akuten CVEs im Mai 2026
Die beiden zentralen Schwachstellen, die aktuell jedes Audit auslösen sollten:
CVE-2026-30623 hat OX intern „Mother of all AI supply chains“ genannt. Der STDIO-Transport in den offiziellen SDKs reicht Argumente ohne Sanitization an die Shell weiter — Arbitrary OS Command Execution, sobald ein Tool-Name oder Parameter geschickt formuliert ist. Anthropics offizielle Antwort: Verhalten ist „by design“, da STDIO als lokaler Trust-Boundary gilt. In der Praxis sehen wir, dass Teams diesen Transport längst in Container-Setups und K8s-Sidecars produktiv einsetzen — dort gilt der Trust-Boundary nicht mehr.
CVE-2026-33032 betrifft die nginx-ui-Integration. Ein offen exponierter /mcp_message-Endpoint erlaubt es jedem Netzwerk-Nachbarn, 12 administrative Tools ohne Authentifizierung aufzurufen. Reload-Tools, Cert-Mgmt, Log-Auslesen — alles ohne Token.
Daneben listet die OX-Disclosure-Welle April/Mai 2026 mehr als zehn weitere High/Critical-CVEs in LiteLLM, LangFlow, Flowise, Windsurf, Langchain-Chatchat, DocsGPT und Agent-Zero. Wer eines dieser Frameworks im Produktivbetrieb hat, sollte heute prüfen.
Sechs Angriffsvektoren, die wir aktuell sehen
Unsere Erfahrung aus Penetrationstests der letzten Monate zeigt sechs wiederkehrende Muster:
Der Postmark-Fall ist instruktiv, weil er kein Bug war, sondern bewusster Rug-Pull: Eine etablierte v1.0-Reihe bekam in v1.0.16 ein heimliches BCC-Feature. Wer ohne Lockfile installierte, blutete still — bis ein Security-Researcher die Mailflüsse analysierte.
Aus unserer Sicht ist die Cross-Server-Variante (Shadowing-Attack) der unterschätzteste Vektor. In Multi-Server-Setups, wie sie in fast jeder Enterprise-Agent-Architektur stehen, liest ein bösartiger Server Kontext-Fragmente aus anderen Servern derselben Session. Das Modell hat keinen Mechanismus, Kontext-Quellen sauber zu trennen — wer einen einzigen kompromittierten Server in der Pipeline hat, hat de facto alle kompromittiert.
Diese Vektoren zielen speziell auf MCP-Pipelines. Für die verwandte Bedrohung durch manipulierte Prompts direkt im Modell-Kontext beschreibt Claude Prompt Injection Schutz 2026: was wirklich hilft die dafür wirksamen Schutzmaßnahmen.
Was Verteidigung im Mai 2026 heißt
Die gute Nachricht: Die Verteidigung ist machbar, sie ist nur unbequem. Sieben Bausteine, die wir bei Kunden aktuell ausrollen.
1. Manifest-Hashing in der CI
Der schnellste Win. Jeder MCP-Server liefert mit list_tools() ein Tool-Manifest. Dieses Manifest pinnen wir beim ersten Audit per SHA-256, prüfen es bei jedem Start und brechen bei Drift den Boot ab:
import hashlib, json
EXPECTED = "9f3b...c2"
manifest = json.dumps(server.list_tools(), sort_keys=True).encode()
if hashlib.sha256(manifest).hexdigest() != EXPECTED:
raise RuntimeError("MCP manifest drift — refusing to load tools")Das fängt Rug-Pulls, versteckte Tool-Description-Updates und stille Manifest-Tausche ab. Pflicht-Build-Step in jeder Agent-Pipeline.
2. Pinned Versions plus Lockfile
Kein latest, kein ^. Versionen exakt pinnen, Lockfile committen, Hashes in der Lockfile aktivieren (pip install --require-hashes, npm ci, cargo --locked).
3. Allowlist statt offene Discovery
Wir betreiben für jeden Kunden einen eigenen MCP-Proxy/Gateway. Modelle dürfen ausschließlich auf die im Gateway hinterlegten Server zugreifen. Public Discovery wird auf Netzwerkebene blockiert. Das schließt Shadow-MCP und Server-Spoofing weitgehend aus.
4. Network-Egress-Restriktion pro Tool-Scope
Jeder MCP-Container darf nur in die Netze, die er konkret braucht. Datenbank-MCP → DB-Subnet, GitHub-MCP → api.github.com, fertig. Ein Tool-Poisoning-Exploit bekommt damit keine Exfil-Route.
5. Sandbox-Isolation
Für STDIO-basierte Server, die wir nicht ablösen können, isolieren wir per Firecracker microVM (Cloud) oder gVisor (K8s). Eine kurze Docker-Lock-Strategie für Teams ohne Firecracker-Setup:
FROM python:3.13-slim
RUN useradd -r -u 10001 mcp && mkdir /srv && chown mcp /srv
USER mcp
WORKDIR /srv
COPY --chown=mcp requirements.lock .
RUN pip install --require-hashes -r requirements.lock
COPY --chown=mcp server.py .
# read-only root, kein /tmp Write, --cap-drop=ALL beim Run
ENTRYPOINT ["python", "server.py"]Dazu im Run-Befehl --read-only --cap-drop=ALL --network=mcp-egress-tight --pids-limit=64 --memory=512m.
6. Input/Output Filtering
mcp-scan, Invariant Guardrails und Prompt-Injection-Filter auf dem Gateway. Wir filtern Tool-Outputs auf bekannte Indirect-Injection-Marker (### system:, ZWSP-Sequenzen, Base64-Blobs mit verdächtigem Entropie-Profil).
7. Audit-Trail in das SIEM
Jeder MCP-Call mit Tool-Name, Argumenten (PII-redacted), Antwort-Hash, Modell-ID und Session-ID nach Splunk/Sentinel. Ohne Audit-Trail kein DORA-Reporting, keine forensische Aufarbeitung, kein Schlafen.
8. Allowlist-Snippet als Referenz
Für Teams, die mit der Allowlist starten, ein minimales JSON-Schema, das wir bei mehreren Kunden im Gateway nutzen:
{
"allowed_servers": [
{
"name": "postgres-readonly",
"url": "https://mcp-gateway.intern/postgres",
"manifest_sha256": "9f3b...c2",
"egress": ["10.42.7.0/24"],
"max_calls_per_min": 60
}
],
"default_action": "deny"
}Anthropic-Update vom 19. Mai 2026
Drei Tage vor Veröffentlichung dieses Beitrags hat Anthropic zwei Mechanismen offiziell ausgerollt:
- Self-hosted Sandboxes (Public Beta) — Integration mit Cloudflare Workers, Daytona, Modal und Vercel. Damit kann ein MCP-Server in einer isolierten Sandbox des eigenen Cloud-Accounts laufen, statt auf dem Agent-Host.
- MCP Tunnels (Research Preview) — Authentifizierte Tunnel zwischen Claude und kundenseitig betriebenen MCP-Servern, ohne dass diese im offenen Internet stehen müssen.
Unsere Empfehlung: Self-hosted Sandboxes für jeden Server testen, der bisher per STDIO oder offen exponiertem HTTP läuft. MCP Tunnels für alle Pipelines mit Banking-, Versicherungs- oder Healthcare-Daten. Beides ersetzt kein Manifest-Hashing — es ergänzt es.
Compliance-Mapping für DACH
Die regulatorische Lage hat sich 2026 verschärft. Die für deutsche und österreichische Mittelständler relevanten Rahmen:
Praktisch heißt das: Wer Claude oder einen anderen Agent in Produktion hat und unter NIS2 fällt, muss bis spätestens Q3 2026 ein MCP-Inventar mit Risiko-Klasse pro Server vorweisen. Banken und Versicherer sind seit Januar 2025 in der Pflicht und müssen Tool-Poisoning-Vorfälle als ICT-Incident binnen 24 Stunden melden — ein Mechanismus, den die wenigsten Häuser heute formal abgebildet haben.
Besonders kritisch wird die Konzentrations-Risiko-Klausel aus DORA Art. 29: Wenn ein erheblicher Teil der Agent-Pipeline auf einem einzigen MCP-Anbieter oder einem einzigen SDK-Hersteller liegt, ist eine dokumentierte Exit-Strategie Pflicht. In unserer Erfahrung scheitern hier 90 Prozent der Banken im ersten Audit — niemand kann auf Knopfdruck einen MCP-Server-Stack auf einen alternativen Anbieter umheben, weil die Tool-Manifests bislang nicht portabel sind.
Der EU AI Act trifft High-Risk-Systeme nach Anhang III ab Dezember 2027, nachdem der Digital Omnibus die Frist verschoben hat. Wer Agent-Pipelines in Kredit-Scoring, HR-Filterung, medizinischen Diagnose-Vorschlägen oder kritischer Infrastruktur einsetzt, muss Prompt-Injection-Resilienz aktiv nachweisen — typischerweise über Red-Team-Reports, Tool-Manifest-Audit-Trails und dokumentierte Filter-Architekturen. Das macht MCP Tool Poisoning vom Security- zum auditrelevanten Compliance-Thema.
Anti-Patterns deutscher Mittelstand
Aus unserer Erfahrung der letzten Quartale acht Muster, die wir in fast jedem Audit finden:
- MCP-Server aus GitHub klonen und installieren — ohne Hash, ohne Versions-Pinning, ohne Lockfile.
- STDIO-Transport in Produktion — statt HTTP mit OAuth, weil die Quickstart-Doku STDIO zeigt.
- MCP-Tokens in
.env— statt Vault, AWS Secrets Manager oder HSM. - Keine Network-Egress-Regeln — MCP-Container darf ins offene Internet.
- Keine Trennung Dev/Prod — Entwickler-Laptops haben Production-Tokens, Production-MCPs werden lokal debuggt.
- „Wir nutzen nur Claude, also safe“ — die Schwachstelle ist im SDK, nicht im Modell. Das Modell macht alles richtig, der SDK-Transport leakt.
- Kein zentrales Inventar — jeder Fachbereich pflegt seine eigenen MCP-Server, der CISO weiss es nicht.
- Compliance-Verantwortung beim AI-Team — statt beim CISO. Damit fällt MCP durch jedes ISMS-Raster.
Die Zahlen aus unserer Kunden-Basis bestätigen den Trend: 65 Prozent der Firmen berichten von mindestens einem AI-Agent-Security-Incident in 2026, 63 Prozent haben keine AI-Governance-Policy. 70 Prozent der Fortune-100 sind Claude-Kunden — und nur ein Bruchteil davon hat ein MCP-Inventar.
Das gefährlichste Muster ist Punkt 6 — „Wir nutzen nur Claude, also safe“. Wir hören diesen Satz in fast jedem Erst-Gespräch mit CIOs. Er verkennt, dass die kritische Lücke (CVE-2026-30623) im SDK-Transport sitzt, nicht im Modell. Claude verarbeitet eine eingehende Tool-Response korrekt; die OS-Command-Execution passiert auf der Maschine, die das SDK lädt. Wer das nicht trennt, schiebt die Verantwortung zum Hersteller, obwohl die Schwachstelle in der eigenen Infrastruktur sitzt.
Ähnlich problematisch ist Punkt 8: Wenn das AI-Team allein für MCP-Compliance verantwortlich zeichnet, fällt das Thema durch jedes ISMS-Raster. Unsere klare Empfehlung: MCP-Security gehört organisatorisch zwischen CISO und Plattform-Team — mit klar dokumentierter RACI, vierteljährlichem Re-Audit und einer einzigen verantwortlichen Person auf C-Level.
FAQ
Was ist MCP Tool Poisoning?
MCP Tool Poisoning bezeichnet jede Manipulation eines MCP-Servers oder seines Tool-Manifests, durch die ein Sprachmodell dazu gebracht wird, schädliche oder unerwünschte Aktionen auszuführen. Das umfasst Tool-Description-Injection, STDIO-Command-Injection, Rug-Pulls und Cross-Server-Data-Leakage.
Wie sicher sind Claude Managed Agents?
Anthropic adressiert mit den Self-hosted Sandboxes und MCP Tunnels (19.05.2026) zwei der grössten Angriffsflächen. Die zugrunde liegende SDK-Schwachstelle (CVE-2026-30623) bleibt aber „by design“ bestehen. Claude Managed Agents sind so sicher wie die MCP-Server, die der Kunde anbindet — die Verantwortung liegt nicht bei Anthropic.
Welche MCP-Server gelten als safe?
„Safe“ ist die falsche Frage. Wir empfehlen einen Whitelist-Ansatz: nur Server, deren Manifest gehashed ist, deren Version gepinnt ist, deren Egress restringiert ist und die in einem Inventar mit Risiko-Klasse stehen. Reputation des Anbieters allein reicht nicht — Postmark hatte Reputation.
Brauche ich einen MCP-Proxy?
Sobald mehr als zwei MCP-Server im produktiven Einsatz sind: ja. Ein Gateway zentralisiert Authentifizierung, Allowlist, Audit-Trail, Rate-Limits und Manifest-Verifikation. Ohne Proxy multipliziert sich der Aufwand mit jedem zusätzlichen Server linear.
Wie auditiere ich MCP-Server in meinem Haus?
In vier Schritten: Inventarisieren (welcher Server, welche Version, welcher Owner), klassifizieren (Risiko nach Datenzugriff und Berechtigungen), scannen (mcp-scan plus eigener Manifest-Hash), härten (Pinning, Egress, Sandbox, Audit-Trail in SIEM). Wir empfehlen einen vierteljährlichen Re-Audit, da das Ökosystem extrem schnell wächst.
Nächster Schritt
MCP Tool Poisoning ist keine Hypothese — die OX-Disclosure-Welle vom April/Mai 2026, der Postmark-Rug-Pull aus September 2025 und die Trend-Micro-Studie zu 492 offenen MCP-Servern haben das in drei verschiedenen Datensätzen belegt. Wer Claude, AutoGen, LangGraph oder ein anderes Agent-Framework produktiv betreibt, läuft Risiken, die unter NIS2 und DORA prüfbar werden.
MCP-Server-Audit für Ihre Agent-Pipelines — kostenfreie Vorab-Analyse
Wir prüfen in einem 90-Minuten-Workshop Ihr MCP-Inventar, identifizieren die kritischen Server nach OX- und Trend-Micro-Mustern, mappen den Befund auf NIS2 Art. 21 und DORA Art. 28–30 und liefern eine priorisierte Maßnahmen-Liste für die nächsten 30 Tage.
