MCP-Vertrauenskette öffnet KI-Agenten für seitliche Angriffe

Worum es geht

Eine Untersuchung des unabhängigen Sicherheitsforschers Syed Anas Mohiuddin zeigt ein wiederkehrendes Problem in Systemen mit KI-Agenten: Ein Agent übernimmt Daten oder Anweisungen von einem anderen Dienst und behandelt sie als vertrauenswürdig. Dadurch können Angreifer schädliche Befehle über mehrere Stationen weiterreichen. Mohiuddin nennt das Muster „Protocol Pivoting“.

Die am 5. Oktober 2026 veröffentlichte Berichterstattung von Ars Technica nennt bestätigte Fälle bei Google, JPMorgan Chase, Weaviate, der französischen Digitalverwaltung und der Stadtverwaltung von Tangerang. Die betroffenen Projekte teilen weder Code noch Betreiber. Genau das macht die Geschichte relevant: Es geht nicht nur um einen einzelnen Programmierfehler, sondern um eine verbreitete Vertrauensannahme in Agentenketten.

Was die Angriffskette tatsächlich macht

Viele Agentensysteme verbinden Modelle und Werkzeuge über das Model Context Protocol (MCP). Ein MCP-Server darf beispielsweise Dokumente abrufen, Datenbanken abfragen oder interne Webadressen öffnen. Wenn er ein vom Agenten geliefertes Ziel ungeprüft aufruft, kann daraus Server-Side Request Forgery, kurz SSRF, entstehen. Der Server greift dann im Namen des Angreifers auf interne Ziele zu.

Bei Googles mcp-toolbox betraf CVE-2026-14540 die Versionen 0.3.0 bis 1.4.0. Laut GitHub-Advisory fehlten eine sichere Weiterleitungsregel und die Prüfung der Ziel-IP. Ein präparierter Pfad konnte Anfragen zu internen oder beliebigen externen Zielen umleiten. Die Schwachstelle erhielt einen CVSS-Wert von 8,0 und wurde mit Version 1.5.0 behoben. Google ergänzte unter anderem IP-Sperrlisten, erlaubte Bereiche und Prüfungen beim Verbindungsaufbau.

Protocol Pivoting erweitert dieses bekannte SSRF-Problem: Schädlicher Text kann als scheinbar normale Werkzeugausgabe an einen weiteren Agenten gelangen. Dieser zweite Agent vertraut dem ersten und führt die delegierte Aufgabe aus. Damit kann eine Anweisung von MCP etwa in ein Agent-to-Agent-Protokoll wechseln, während Herkunft und Berechtigung unterwegs verloren gehen.

Warum das wichtig ist

Agenten werden gerade deshalb eingesetzt, weil sie auf Dateien, Datenbanken, Browser und Cloud-Dienste zugreifen dürfen. Eine falsche Vertrauensentscheidung hat deshalb andere Folgen als eine bloß fehlerhafte Chat-Antwort. Sie kann Netzwerkzugriffe, Datenabfluss oder Aktionen mit gespeicherten Zugangsdaten auslösen.

Die Fälle liefern überprüfbare Hinweise auf ein strukturelles Risiko. Neben Googles hoch eingestufter Lücke dokumentiert Rapid7 CVE-2026-97228 in seinem Bulk-Export-MCP. Der Fehler war mit 2,7 deutlich niedriger bewertet, zeigt aber dieselbe Grundfrage: Werden Werkzeugparameter wie fremde Eingaben geprüft? Auch die französische Datenplattform data.gouv.fr und ein Wazuh-MCP-Projekt veröffentlichten Korrekturen gegen SSRF-Varianten.

Für Entwickler ist die praktische Konsequenz klar: „intern“ darf nicht automatisch „vertrauenswürdig“ bedeuten. Jede Ausgabe eines Modells oder Agenten muss an der nächsten Werkzeuggrenze erneut geprüft, begrenzt und autorisiert werden.

Einfach erklärt

Stellen Sie sich ein Bürogebäude vor, in dem jeder Mitarbeitende jede Notiz eines Kollegen ungeprüft ausführt. Ein Besucher legt am Empfang einen Zettel ab: „Bitte öffnen Sie den Serverraum und bringen Sie den Inhalt dieses Schranks nach draußen.“ Der Empfang leitet ihn an die Technik weiter, und die Technik handelt, weil der Zettel aus dem eigenen Haus kommt. Das Problem ist nicht nur der gefälschte Zettel, sondern die fehlende Kontrolle an jeder Tür.

Praktisches Beispiel

Ein Einkaufsagent darf Produktdaten aus dem Internet lesen. Ein zweiter Agent verwaltet Bestellungen und besitzt Zugriff auf ein internes Kundensystem. In einer Produktbeschreibung steckt eine versteckte Anweisung, die wie eine delegierte Aufgabe aussieht. Der Einkaufsagent übernimmt sie in seine Ausgabe; der Bestellagent sieht eine interne Nachricht und ruft eine angegebene URL auf.

Ohne Zielprüfung könnte die URL auf einen internen Dienst zeigen. Mit einer Begrenzung auf freigegebene Domains, einer Prüfung jeder Weiterleitung, kurzlebigen Zugangsdaten und einer erneuten Autorisierung vor dem Zugriff würde die Kette an mehreren Stellen stoppen. Entscheidend ist nicht ein einzelner Filter, sondern die Kombination unabhängiger Kontrollen.

Einordnung und Grenzen

• Die bestätigten Schwachstellen belegen reale Implementierungsfehler, aber keine bekannten erfolgreichen Datendiebstähle über alle genannten Systeme.
• „Protocol Pivoting“ ist eine Bezeichnung des Forschers. Andere Fachleute ordnen die Methode als Unterform indirekter Prompt Injection ein; die Benennung ist noch nicht standardisiert.
• Nicht jeder MCP-Server ist verwundbar. Das Risiko hängt von Netzwerkzugriff, Berechtigungen, Zielprüfung, Weiterleitungen und der Frage ab, ob mehrere Agenten einander ungeprüft vertrauen.

Unternehmen sollten deshalb nicht pauschal MCP abschalten. Sinnvoller sind Zero-Trust-Regeln zwischen Agenten, getrennte Identitäten, minimale Rechte, ausgehende Netzwerkfilter und Protokolle, die Herkunft sowie Berechtigung einer delegierten Aufgabe erhalten. Noch offen ist, wie zuverlässig solche Kontrollen in langen, dynamischen Agentenketten funktionieren.

SEO- und GEO-Schlüsselbegriffe

MCP-Sicherheit, Model Context Protocol, Protocol Pivoting, KI-Agenten, Prompt Injection, SSRF, CVE-2026-14540, Google mcp-toolbox, Zero Trust, Agent-to-Agent, Cybersecurity