Ihr Agent hat einen Mittelsmann, den Sie nicht geprüft haben

Forscher kauften 28 kostenpflichtige LLM-API-Router bei Taobao, Xianyu und auf Shopify gehosteten Shops und sammelten 400 kostenlose aus öffentlichen Communitys. Bei jedem registrierten sie ein Konto, ließen einen Coding-Agenten in einer Sandbox darüber laufen, führten jeden zurückkommenden Tool-Aufruf aus und beobachteten, was er tat.¹

Neun der 428 Router schrieben einen Tool-Aufruf in einen vom Angreifer kontrollierten Befehl oder eine Abhängigkeit um: ein kostenpflichtiger und acht kostenlose. Siebzehn kostenlose Router verwendeten anschließend ein AWS-Canary-Credential, nachdem sie es im Datenverkehr gesehen hatten, und einer leerte einen platzierten Ethereum-Schlüssel. Zwei der einschleusenden Router verbargen ihr Verhalten. Einer wartete 50 Anfragen ab, bevor er handelte, und einer schlug nur bei Sitzungen im autonomen „YOLO mode“ (Werkzeugaufrufe werden ohne Rückfrage freigegeben) zu, die an Rust- oder Go-Projekten arbeiteten.¹

Ein LLM-API-Router ist ein Proxy auf Anwendungsebene. Er terminiert TLS, liest jede Anfrage und jede Antwort im Klartext und kann den Tool-Aufruf umschreiben, den Ihr Agent gleich ausführen wird. Das Paper fand keinen großen Anbieter, der seine Tool-Call-Antworten signiert; nichts verknüpft also den Befehl, den Ihr Agent ausführt, mit dem, was das Modell erzeugt hat. Getestet wurden vier Agenten-Frameworks, darunter Claude Code und Codex, und keines prüfte die Integrität der Antwort.¹

Dieser Beitrag erschien erstmals am 10. April 2026 auf Grundlage der Kurzfassung des Papers. Am 2. Oktober 2026 habe ich ihn anhand des vollständigen Textes neu geschrieben. Die April-Fassung lag in mehreren Punkten falsch; sie sind gegen Ende unter „Was die April-Fassung falsch machte“ aufgeführt.

TL;DR

• Was ein Router kann. Er sitzt als der von Ihnen konfigurierte Endpunkt zwischen Ihrem Client und dem Modellanbieter, hält also den Klartext jeder Anfrage und jeder Antwort in der Hand und kann beides vor der Weitergabe verändern.¹
• Was 428 Router taten. Neun schleusten bösartigen Code in zurückgegebene Tool-Aufrufe ein (1 von 28 kostenpflichtigen, 8 von 400 kostenlosen). Zwei der kostenlosen verbargen das hinter Auslösern. Siebzehn kostenlose Router nutzten ein AWS-Canary-Credential der Forscher, und einer leerte einen Ethereum-Schlüssel der Forscher mit einem Guthaben unter 50 $.¹
• Was geleakte Schlüssel und schwache Relays bewirkten. Ein absichtlich geleakter OpenAI-Schlüssel lieferte 100 Mio. GPT-5.4-Tokens und legte mehr als sieben Codex-Sitzungen offen. Schwach konfigurierte Köder-Relays lieferten rund 2 Mrd. Tokens und legten 99 Credentials aus 440 Codex-Sitzungen offen, von denen 401 Tool-Aufrufe bereits automatisch freigaben.¹
• Was die Abwehrmaßnahmen leisteten. Im synthetischen Benchmark der Autoren blockierte ein Fail-closed-Policy-Gate jede Injektionsprobe bei 1,0 % Fehlalarmen; in einem einfachen adaptiven Benchmark umging ein Angreifer, der das Gate kannte, es in 100 % der Proben. Die Anomalieprüfung markierte 89,0 % der einfachen Injektionen und etwa die Hälfte der verschleierten.¹
• Was laut den Autoren das Problem lösen würde. Ein vom Anbieter signierter Antwort-Umschlag, mit dem ein Client einen Tool-Aufruf gegen die Ausgabe des Modells prüfen kann. Das Paper fand keinen großen Anbieter, der so etwas ausliefert.¹
• Wenn Sie den Router selbst hosten. Das Update vom 1. Oktober weiter unten behandelt elf LiteLLM-Advisories; eines davon erlaubte jedem authentifizierten Benutzer, den Proxy dazu zu bringen, seine Anbieterschlüssel nach außen zu senden.²

Wichtigste Erkenntnisse

• Agenten-Betreiber: Jeder Router zwischen Ihrem Client und dem Modellanbieter hat Klartextzugriff auf jede Anfrage und jede Antwort, und der Client konfiguriert nur den ersten Hop. Haben Sie einen Router auf einem Marktplatz gekauft oder aus einer öffentlichen Liste übernommen, behandeln Sie ihn als feindselige Zwischeninstanz, bis Sie einen eigenständigen Grund haben, dem Betreiber zu vertrauen.
• Harness-Entwickler: Ein PreToolUse-Hook läuft, bevor ein Tool-Aufruf ausgeführt wird, und bis dahin hatte ein Router längst Gelegenheit, diesen Aufruf umzuschreiben. Der Hook hat kein Original zum Vergleich. Was er kann: fail-closed arbeiten. Shell-Befehle nur dann zulassen, wenn sie ausschließlich von gelisteten Domains laden und ausschließlich gelistete Pakete installieren, und alles andere blockieren.³
• Alle, die YOLO mode nutzen: In der Köderstudie der Forscher liefen 401 von 440 beobachteten Codex-Sitzungen bereits mit automatisch freigegebener Tool-Ausführung.¹ In diesen Sitzungen wäre ein schlicht umgeschriebener Befehl ausgeführt worden, ganz ohne Auslöserlogik. Leiten Sie automatisch freigegebene Sitzungen nicht über einen Router, den Sie nicht kontrollieren.
• Teams mit eigenem Proxy: Ein Router, den Sie selbst betreiben, bündelt Anbieterschlüssel genauso. Unter elf LiteLLM-Advisories, die am 1. Oktober 2026 in die PyPA-Datenbank gelangten und größtenteils seit Juni öffentlich sind, ist eines, das jedem authentifizierten Benutzer erlaubte, den Proxy seine Anbieterschlüssel an einen Host seiner Wahl senden zu lassen. Releases ab 1.97.0 liegen außerhalb aller elf erfassten Bereiche; Details im Update vom 1. Oktober weiter unten.²

Was ist eigentlich ein Router?

Ein LLM-API-Router nimmt Anfragen in einem Format entgegen, meist OpenAI-kompatibel, wählt einen vorgelagerten Anbieter aus und gibt die Antwort zurück. Das Paper zählt Router jeder Größenordnung dazu: Cloud-verwaltete Dienste wie Amazon Bedrock und Azure OpenAI Service, entwicklerorientierte Projekte und Dienste wie LiteLLM und OpenRouter sowie einen Massenmarkt für weiterverkauften und gebündelten API-Zugang.¹

Für ihren Einsatz gibt es gute Gründe. Das Paper nennt „model fallback, load balancing, cost optimization, and a single API key across providers“ (Ausweichmodelle, Lastverteilung, Kostenoptimierung und ein einziger API-Schlüssel für alle Anbieter) und merkt an, dass Routing besonders verbreitet ist „in regions where direct provider access is restricted, expensive, or subject to quota limitations“ (in Regionen, in denen der direkte Anbieterzugang eingeschränkt, teuer oder kontingentiert ist).¹

Das Problem ist die Position. Es braucht keinen Abfangtrick, in den Worten des Papers: „the client voluntarily configures the router’s URL as the API endpoint, the router terminates the client-side TLS connection, and it originates a separate TLS connection upstream“ (der Client trägt die URL des Routers freiwillig als API-Endpunkt ein, der Router terminiert die clientseitige TLS-Verbindung und baut eine eigene TLS-Verbindung nach oben auf). TLS schützt jede Teilstrecke. Vor dem Router selbst schützt es die Nutzdaten nicht: Er liest das JSON der Anfrage, leitet es weiter, liest das JSON der Antwort und gibt es zurück, und beides kann er dabei verändern.¹

Router lassen sich zudem verketten. Das Beispiel im Paper: Ein Entwickler kauft Zugang bei einem Taobao-Wiederverkäufer, der Schlüssel von einem Aggregator der zweiten Ebene bündelt, der wiederum über OpenRouter routet, das an den Modellhost weiterleitet. Vier Hops, jeder mit vollem Klartextzugriff. „The client configures only the first hop; subsequent hops are invisible.“ (Der Client konfiguriert nur den ersten Hop; alle weiteren bleiben unsichtbar.) Ein einziger schlechter Hop irgendwo verdirbt den Pfad, und die ehrlichen Hops danach können das nicht erkennen.¹

Nichts in den heutigen APIs schließt diese Lücke. Argumente von Tool-Aufrufen reisen als Klartext-JSON, und „No provider-level integrity mechanism binds the arguments returned by the model to the arguments received by the client.“ (Kein Integritätsmechanismus auf Anbieterebene bindet die vom Modell zurückgegebenen Argumente an die beim Client eingehenden.)¹

Wie die Messung ablief

Für jeden Router durchliefen die Autoren vier Stufen. Sie registrierten ein von ihnen kontrolliertes Konto und erhielten API-Zugangsdaten. Dieses Konto leiteten sie durch eine Agentenumgebung in einer Sandbox, die „a randomized subset of custom tasks and TerminalBench 2.0 tasks“ (eine zufällige Auswahl eigener Aufgaben und TerminalBench-2.0-Aufgaben) abarbeitete; diese erzeugen realistische Tool-Aufrufe für Shell, Paketinstallation und Dateibearbeitung. Jede zurückgegebene Tool-Call-Nutzlast führten sie in der Sandbox aus, die auf Netzwerk-Callbacks, Änderungen am Dateisystem und Auffälligkeiten im Prozessbaum achtete. Ein separater Analyse-Agent prüfte anschließend markierte Ausführungen und stufte jede als harmlose Umschreibung, möglicherweise bösartig oder bestätigt bösartig ein.¹

Die Definitionen sind konservativ. Ein Router gilt nur dann als Einschleuser bösartigen Codes, „only if a returned tool-call payload is rewritten into an attacker-controlled command or dependency“ (wenn eine zurückgegebene Tool-Call-Nutzlast in einen vom Angreifer kontrollierten Befehl oder eine solche Abhängigkeit umgeschrieben wird). Ein AWS-Canary gilt als angefasst, wenn ein Credential, das den Router passiert hat, „later produces follow-on AWS API activity attributable to that credential“ (später nachfolgende AWS-API-Aktivität erzeugt, die diesem Credential zuzuordnen ist).¹

Der Datenbestand bildet den Massenmarkt ab, nicht das ganze Feld. Die 400 kostenlosen Router stammen überwiegend von zwei Open-Source-Vorlagen, sub2api und new-api, und Unternehmens- sowie Nur-auf-Einladung-Deployments liegen laut den Autoren außerhalb der Studie. Der Großteil stammt von chinesischsprachigen Marktplätzen und Communitys.¹

Die Felddaten

Die Injektionen sind keine Kosmetik. Laut Paper „change the command or dependency that the agent intends to execute“ (ändern sie den Befehl oder die Abhängigkeit, die der Agent ausführen will). Bei den kostenpflichtigen Routern ist es einer von 28, und die Autoren ziehen den nüchternen Schluss: „Paid access improves service stability, but it does not prove tool-call integrity.“ (Bezahlter Zugang verbessert die Stabilität des Dienstes, beweist aber nicht die Integrität der Tool-Aufrufe.)¹

Die beiden Router mit Auslösern sind der Befund, der Tests aushebelt. Beim einen gilt: „malicious tool calls are injected only after the first 50 requests, which hides the attack from shallow smoke tests“ (bösartige Tool-Aufrufe werden erst nach den ersten 50 Anfragen eingeschleust, was den Angriff vor oberflächlichen Smoke-Tests verbirgt). Beim anderen ist die Injektion aktiv „only for sessions that appear to be running in autonomous YOLO mode and only when the project fingerprint matches Rust or Go“ (nur für Sitzungen, die im autonomen YOLO mode zu laufen scheinen, und nur, wenn der Projekt-Fingerabdruck auf Rust oder Go passt). Die Autoren ergänzen, dass die beobachteten Auslöser womöglich nicht die einzigen sind. Sie haben diese Router nur durch endliche Black-Box-Tests beobachtet, daher „a router may implement additional latent conditions that our probes did not activate“ (kann ein Router weitere verborgene Bedingungen implementieren, die ihre Tests nicht ausgelöst haben).¹

Die Credential-Befunde entfallen sämtlich auf die kostenlosen Router. Siebzehn Router „trigger follow-on use of at least one researcher-owned AWS canary credential after seeing it in transit“ (lösen die nachfolgende Nutzung mindestens eines AWS-Canary-Credentials der Forscher aus, nachdem sie es im Datenverkehr gesehen haben), und einer leerte einen vorab aufgeladenen Ethereum-Schlüssel. Laut Anhang lag der Verlust durch diese Abbuchung unter 50 US-Dollar.¹

Die zwei Vergiftungs-Studien

Ein Router muss nicht bösartig sein, um in dieselbe Position zu geraten. Die Autoren führten zwei Studien dazu durch, wie ein harmlos wirkender Routerpfad vergiftet wird.

Studie 1: ein geleakter Schlüssel. Sie leakten einen eigenen OpenAI-API-Schlüssel „on Chinese forums, WeChat, and Telegram groups frequented by router operators“ (in chinesischen Foren, WeChat- und Telegram-Gruppen, in denen sich Routerbetreiber aufhalten). Dieser eine Schlüssel lieferte 100 Mio. GPT-5.4-Tokens und legte mehr als sieben Codex-Benutzersitzungen offen; in mindestens einer Sitzung tauchten dahinter mehrere verschiedene Credentials auf. Das Paper formuliert vorsichtig, wie der Datenverkehr dorthin gelangte. Das Ergebnis „is consistent with several paths: direct reuse by a router operator, direct reuse by unrelated third parties, or reuse somewhere inside a longer relay chain“ (passt zu mehreren Wegen: direkte Wiederverwendung durch einen Routerbetreiber, direkte Wiederverwendung durch unbeteiligte Dritte oder Wiederverwendung irgendwo in einer längeren Relay-Kette), und die Autoren „cannot always distinguish among those paths from provider-side logs alone“ (können diese Wege allein anhand anbieterseitiger Logs nicht immer unterscheiden). Was die Studie belegt, ist der Wirkungsradius: Wer einen wiederverwendeten vorgelagerten Schlüssel besitzt, sieht den Datenverkehr dahinter im Klartext.¹

Studie 2: schwache Relays. Sie setzten verwundbare claude-relay-service-Instanzen auf 20 Domains sowie Sub2API- und CLIProxyAPI-Instanzen mit schwachen Passwörtern auf 20 IPs ein. Die Köder zogen mehr als 40.000 unbefugte Zugriffsversuche von 147 IPs an, was die Autoren als Mischung aus Scans und Relay-Wiederverwendung deuten und nicht in jedem Fall als gezielte Angriffe. Das stärkere Signal kam später: Die Köder „were folded into active agent-facing relay paths“ (wurden in aktive, Agenten bedienende Relay-Pfade eingebunden). Sie lieferten rund 2 Mrd. GPT-5.4- und 5.3-codex-Tokens, etwa 13 GB sichtbaren Prompt- und Antwortverkehr, und legten 99 eindeutige Credentials aus 440 Codex-Sitzungen offen, verteilt auf 398 Projekte oder Hosts.¹

Jede dieser 440 Sitzungen war nach der Definition des Papers für Befehlsinjektion anfällig, und 401 „already operated in YOLO mode, i.e., with tool execution auto-approved rather than confirmed command by command“ (liefen bereits im YOLO mode, also mit automatisch freigegebener Tool-Ausführung statt Bestätigung Befehl für Befehl). Für diese 401, schreiben die Autoren, „sophisticated adaptive evasion was unnecessary: basic payload injection would have been sufficient to change executed commands“ (war ausgefeilte adaptive Verschleierung unnötig: eine einfache Nutzlast-Injektion hätte gereicht, um ausgeführte Befehle zu ändern).¹

Das waren Sitzungen anderer Leute. Ihr Datenverkehr erreichte die Köder der Forscher, nachdem diese in Relay-Pfade eingebunden worden waren, und ein Benutzer, der nur den ersten Hop konfiguriert, hätte das nicht erkennen können. Die Autoren bewahrten nur aggregierte Metadaten und gesalzene Hashes auf und zogen ihre eigenen offengelegten Credentials zum Ende des Beobachtungszeitraums aus dem Verkehr.¹

Zwei zentrale Angriffsklassen und zwei Verschleierungsvarianten

Das Paper reduziert das Verhalten bösartiger Router auf zwei Grundformen und zwei Verfeinerungen der ersten.¹

AC-1: antwortseitige Nutzlast-Injektion. Der Router schreibt einen Tool-Aufruf um, nachdem dieser den Anbieter verlassen hat und bevor er den Client erreicht, und lässt Tool-Namen und Schema dabei unangetastet. Das Beispiel im Paper ist ein Bash-Aufruf, dessen Installer-URL durch die eines Angreifers ersetzt wird. Weil das Ergebnis für das erwartete Tool weiterhin gültiges JSON ist, wirkt für den Client nichts falsch.

AC-2: passive Exfiltration von Geheimnissen. Der Router ändert nichts. Er durchsucht Anfragen und Antworten nach Mustern von Zugangsdaten und behält, was er findet. Der Datenverkehr bleibt unverändert, daher „clients cannot observe router-side retention“ (können Clients die routerseitige Speicherung nicht beobachten). Gefährdet ist mehr als nur API-Schlüssel: „system prompts, tool definitions, user-supplied file contents, and environment variables all transit the same plaintext channel“ (System-Prompts, Tool-Definitionen, vom Benutzer gelieferte Dateiinhalte und Umgebungsvariablen laufen alle über denselben Klartextkanal).

AC-1.a: auf Abhängigkeiten zielende Injektion. Eine Variante von AC-1, die auf Befehle zur Paketinstallation zielt. Statt eine URL auszutauschen, „substitutes a legitimate dependency name with an attacker-controlled package pre-registered on the target registry“ (ersetzt der Router einen legitimen Abhängigkeitsnamen durch ein vom Angreifer kontrolliertes, vorab in der Ziel-Registry registriertes Paket). Im Beispiel des Papers wird aus pip install requests ein pip install reqeusts. Der Befehl installiert weiterhin aus der vertrauenswürdigen Registry, ein Gate, das nur Domains prüft, lässt ihn also passieren, und das schädliche Paket bleibt für spätere Sitzungen im Cache.

AC-1.b: bedingte Auslieferung. Eine Variante, die festlegt, wann AC-1 zuschlägt. Der Router verhält sich ehrlich, bis ein Auslöser greift. Das Paper nennt fünf Familien von Auslösern: Tool-Name, Inhaltsschlüsselwörter, Benutzer-Fingerabdrücke wie YOLO mode, Zeitfenster und Anfragezähler. „A router deploying a 50-request warm-up appears entirely transparent during a 10-request probe.“ (Ein Router mit einer Aufwärmphase von 50 Anfragen wirkt bei einem Test mit 10 Anfragen völlig transparent.)

Das Paper nennt die LiteLLM-Kompromittierung vom März 2026 als AC-1 im großen Maßstab: Sobald ein Angreifer die Anfrage-Pipeline des Proxys kontrollierte, lag jeder durchlaufende Tool-Aufruf zum Umschreiben offen. (Das Paper beschreibt diese Kompromittierung als Dependency Confusion. Die Berichte, auf die ich mich in dem Beitrag zur Lieferkette gestützt habe, führen sie auf ein PyPI-Veröffentlichungstoken zurück, das über die Trivy-Kompromittierung gestohlen wurde.)

Was der Forschungsproxy über Agenten-Clients zeigte

Die Autoren bauten einen Proxy namens Mine, der alle vier Klassen implementiert, und schickten pro Angriffsmodul 1.000 Tool-Call-Anfragen durch jedes von vier öffentlichen Agenten-Frameworks: OpenClaw, OpenCode, OpenAIs Codex und Anthropics Claude Code.¹

Keines der vier prüfte die Integrität der Antwort. Der umgeschriebene Tool-Aufruf kam in 100 % der AC-1-Fälle und 99,6 % der AC-1.a-Fälle in gültiger, framework-nativer Form an. Das Paper sagt genau, was das zeigt und was nicht: „These are compatibility measurements, not end-to-end execution rates: they show that the tampered tool call reaches the client in a valid framework-native format, but downstream permission prompts or local execution sandboxes may still block the resulting action.“ (Dies sind Kompatibilitätsmessungen, keine End-to-End-Ausführungsraten: Sie zeigen, dass der manipulierte Tool-Aufruf den Client in gültigem, framework-nativem Format erreicht, nachgelagerte Berechtigungsabfragen oder lokale Ausführungs-Sandboxes die resultierende Aktion aber dennoch blockieren können.)¹

Genau an diesem Vorbehalt zeigt sich der Wert einer Berechtigungsabfrage, und deshalb wiegt die automatische Freigabe in den Köderzahlen so schwer. Die Autoren haben Mine nicht veröffentlicht.¹

Das Kompositionsmuster, eine Schicht tiefer

Ich schreibe immer wieder über denselben strukturellen Fehler: Einzeln autorisierte Komponenten setzen sich zu nicht autorisiertem Verhalten zusammen. Trivy-to-LiteLLM war Komposition auf der Paketebene. Silent Egress war Komposition auf der Ebene abgerufener Inhalte. MCP-Tool-Poisoning war Komposition auf der Protokollebene.

Der Router-Angriff ist Komposition auf dem Hop zwischen Client und Anbieter. Ihr Client darf den Router aufrufen. Der Router darf das vorgelagerte Modell aufrufen. Das Modell darf antworten. Jeder Hop ist autorisiert, und die Komposition liefert trotzdem umgeschriebene Befehle, weil niemand signiert, was den Hop passiert, und kopierte Geheimnisse, weil jeder Hop es im Klartext liest.

Das Paper zieht die Linie bis zu MCP selbst: „a malicious MCP server receives tool-call requests in plaintext and can return forged results, so the same basic manipulation and collection ideas transfer with adaptation to the MCP message format“ (ein bösartiger MCP-Server empfängt Tool-Call-Anfragen im Klartext und kann gefälschte Ergebnisse zurückgeben, sodass sich dieselben Grundideen der Manipulation und des Abgreifens, angepasst an das MCP-Nachrichtenformat, übertragen lassen). Es benennt auch den Unterschied. Ein MCP-Server sitzt auf der Seite der Tool-Ausführung und kann Tool-Ausgaben fälschen. Ein Router sitzt auf dem Weg zum Modell und sieht jeden Tool-Aufruf sowie den gesamten Anfragekontext.¹

Drei Abwehrmaßnahmen, mit den Zahlen des Papers

Das Paper bewertet drei Kontrollen, die ein Client ohne Hilfe eines Anbieters einsetzen kann. Für jede Zahl unten gilt ein Vorbehalt: „All numbers in this section come from controlled artifact-side evaluation rather than field data.“ (Alle Zahlen dieses Abschnitts stammen aus einer kontrollierten Evaluierung am Forschungsartefakt, nicht aus Felddaten.) Die Datensätze sind synthetisch und wurden von Skripten der Autoren erzeugt.¹

Das Policy-Gate blockiert Shell-Befehle, die „fetch from non-allowlisted domains or install packages outside a local allowlist“ (von nicht freigegebenen Domains laden oder Pakete außerhalb einer lokalen Allowlist installieren). Bei 1.000 harmlosen Befehlen, 500 AC-1-Proben und 500 AC-1.a-Proben blockierte es jede Angriffsprobe, und sämtliche Fehlalarme waren Installer-Downloads von Mirror-Domains, die in der Allowlist fehlten. Die Autoren nennen es „the strongest immediately deployable control“ (die stärkste sofort einsetzbare Kontrolle). Sein Versagen berichten sie ebenso offen. Legt der Angreifer die Nutzlast auf eine freigegebene Domain oder platziert vorab ein lokales Skript, das später ein harmlos wirkender Befehl ausführt, gilt: „the policy gate is bypassed in 100% of samples“ (das Policy-Gate wird in 100 % der Proben umgangen). Ihr Urteil: Das Gate „should be understood as a coarse but useful filter for obvious high-risk workflows, not as a robust defense against defense-aware attackers“ (ist als grober, aber nützlicher Filter für offensichtlich riskante Abläufe zu verstehen, nicht als robuste Verteidigung gegen Angreifer, die die Abwehr kennen).¹

Ein Detail ist für alle wichtig, die das Gate bauen, und das Paper ist darin nicht einheitlich. Abschnitt 4 beschreibt das Gate als reine Domainprüfung und entwirft AC-1.a, um es zu schlagen: „the gate blocks non-allowlisted domains but does not maintain a per-package allowlist“ (das Gate blockiert nicht freigegebene Domains, führt aber keine Allowlist pro Paket). Das Gate aus Abschnitt 7, das gegen AC-1.a 100 % erzielte, blockiert auch Installationen „outside a local allowlist“ (außerhalb einer lokalen Allowlist). Nach meiner Lesart verfehlt ein Gate ohne Paketliste die Typosquatting-Ersetzung vollständig.

Die Anomalieprüfung bewertet jeden zurückgegebenen Tool-Aufruf anhand lokal sichtbarer Merkmale wie Shell-Risikomustern und Argument-Entropie, ohne ein vorgelagertes Original zum Vergleich. Bei 6,7 % Fehlalarmen markierte sie 89,0 % der AC-1-Proben, 50,0 % von AC-1.a und 50,9 % von AC-1.b. Bei einem Fehlalarmbudget von 1 % erfasste sie 43,5 % von AC-1 und praktisch nichts von AC-1.a. Die Autoren halten sie für „useful for review prioritization“ (nützlich, um Prüfungen zu priorisieren) und für schwächer als das Gate.¹

Das Transparenzprotokoll zeichnet Anfrage, Antwort, Router-URL, TLS-Metadaten und einen Hash der Rohantwort auf. Es verhindert nichts. Es erlaubt Ihnen nach einem Vorfall zu beantworten, wie weit ein Router oder ein Credential reichte und welche Sitzungen darüber liefen.¹

Die Lösung, die die Autoren fordern

Keine der drei Kontrollen authentifiziert, woher ein Tool-Aufruf stammt. Die Autoren sagen es offen: „No client-side control available today can prove that a router preserved the upstream provider’s response.“ (Keine heute verfügbare clientseitige Kontrolle kann beweisen, dass ein Router die Antwort des vorgelagerten Anbieters unverändert gelassen hat.)¹

Das könnte eine Signatur des Anbieters. Das Paper schlägt „a provider-signed canonical response envelope, similar in spirit to DKIM for email“ (einen vom Anbieter signierten kanonischen Antwort-Umschlag, im Geist ähnlich DKIM bei E-Mail) vor, der Modellkennung, Tool-Namen, Tool-Argumente, Abschlussgrund und eine Client-Nonce abdeckt und den der Client vor der Ausführung jedes Tool-Aufrufs prüft. Laut Paper liefert das niemand aus: „To our knowledge, none of the major provider tool-use APIs or the current MCP specification expose a deployed response-signing mechanism for tool-call arguments today.“ (Unseres Wissens bietet heute keine der Tool-Use-APIs der großen Anbieter und auch nicht die aktuelle MCP-Spezifikation einen eingesetzten Mechanismus zur Signatur von Tool-Call-Argumenten.)¹

Der Vorschlag hat zwei Grenzen. Transportsicherheit ersetzt ihn nicht: Mutual TLS und Certificate Pinning „can authenticate the router endpoint the client chose, but they do not say whether the returned tool call preserves upstream semantics“ (können den vom Client gewählten Router-Endpunkt authentifizieren, sagen aber nichts darüber, ob der zurückgegebene Tool-Aufruf die vorgelagerte Bedeutung bewahrt). Und gegen gestohlene Geheimnisse hilft eine Signatur nicht: „AC-2 cannot be mitigated by response-signing proposals because the secrets are exposed on the request path before any provider-side mechanism can act.“ (AC-2 lässt sich durch Antwortsignaturen nicht entschärfen, weil die Geheimnisse auf dem Anfrageweg offenliegen, bevor irgendein anbieterseitiger Mechanismus greifen kann.)¹

Was Sie tatsächlich tun sollten

Wenn Ihr Agent ein Modell über einen Router aufruft, den Sie nicht selbst gebaut haben:

1. Gehen Sie direkt, wo Sie können, und kennen Sie den Betreiber, wo Sie es nicht können. Ein Router ist mit einer geänderten Basis-URL eingebunden, und genau deshalb kommt er ohne jede Entscheidung hinzu. Treffen Sie diese Entscheidung. „Vertrauen“ heißt hier eine externe Grundlage, etwa ein bekanntes Team, ein Vertrag oder eine Rechtsordnung, in der Sie Ansprüche durchsetzen können. Marktplatzbewertungen gehören nicht dazu.
2. Arbeiten Sie bei riskanten Tool-Aufrufen fail-closed. In Claude Code ist das ein PreToolUse-Hook, der Shell-Befehle blockiert, die von Domains außerhalb einer Allowlist laden, sowie Paketinstallationen außerhalb einer Allowlist. Behalten Sie die Paketliste bei: Die Variante mit Abhängigkeitsersetzung existiert, um ein reines Domain-Gate zu schlagen. Schreiben Sie den Hook so, dass er alles ablehnt, was er nicht parsen kann, mit Exit-Code 2 oder einer deny-Entscheidung. Claude Code behandelt andere Exit-Codes und Timeouts als nicht blockierend, ein abstürzender oder hängender Hook hält den Aufruf also nicht auf: Der läuft dann durch den normalen Berechtigungsablauf und wird in einer automatisch freigegebenen Sitzung einfach ausgeführt. Prüfen Sie außerdem, ob der Hook beim ersten Aufruf überhaupt lief. Die Dokumentation warnt: „a mistyped path in settings.json leaves the gate silently disabled“ (ein Tippfehler im Pfad in settings.json lässt das Gate stillschweigend deaktiviert). Rechnen Sie damit, beide Listen pflegen zu müssen, und damit, dass ein entschlossener Angreifer sie umgeht.³
3. Leiten Sie automatisch freigegebene Sitzungen nie über einen Router, den Sie nicht kontrollieren. Die 401 Sitzungen der Köderstudie sind der Präzedenzfall. Eine Berechtigungsabfrage gehört zu den wenigen Dingen, die zwischen einem umgeschriebenen Tool-Aufruf und seiner Ausführung stehen.
4. Halten Sie Geheimnisse aus dem Datenverkehr heraus. Passives Abgreifen verändert nichts, was Sie beobachten könnten. Alles in einem Prompt, einem Tool-Ergebnis oder einer Datei, die der Agent liest, passiert den Router im Klartext. Schränken Sie Credentials eng ein, halten Sie sie nach Möglichkeit aus dem Kontext heraus und rotieren Sie alles, was einen Router passiert hat, dem Sie später misstrauen.
5. Protokollieren Sie lokal. Anfragen, Antworten, die Router-URL und einen Antwort-Hash, wobei Geheimnisse zuvor aus den Anfragen entfernt werden, gespeichert dort, wo der Router nicht hinkommt. Einen Angriff stoppt das nicht. Es zeigt Ihnen hinterher, was offengelegt wurde.
6. Führen Sie in einer Sandbox aus. Das Paper hält fest, dass Sandboxes „reduce post-execution blast radius but do not authenticate where a tool call came from“ (den Wirkungsradius nach der Ausführung verringern, aber nicht authentifizieren, woher ein Tool-Aufruf stammt). Nehmen Sie die erste Hälfte mit.

Die unbequeme Implikation

Die Router-Schicht ist ein klares Beispiel dafür, wie das Agenten-Ökosystem Infrastruktur schneller ausliefert, als es sie absichert. Man will einen Schlüssel für jedes Modell, niedrigere Preise und Zugang aus Regionen, die ein Anbieter nicht bedient. Router liefern alle drei, und der Markt belohnt sie dafür.

Dieselbe Abfolge hat sich bereits auf der MCP-Ebene, der Paketebene und der Ebene abgerufener Inhalte abgespielt. Eine neue Schicht des Agenten-Stacks entsteht. Entwickler übernehmen sie, bevor jemand sie prüft. Erst kommen die Angreifer, dann die Forscher. Hier zählten die Forscher 428 Router, 9 davon schleusten bösartigen Code ein, 17 nutzten platzierte Credentials, 1 leerte eine Wallet, und 401 automatisch freigegebene Sitzungen liefen über Relay-Pfade, zu denen auch die Köder der Forscher gehörten.¹

Das Teil, das die Lücke schließen würde, eine vom Anbieter signierte Antwort, kann kein Betreiber selbst hinzufügen. Bis die Anbieter es ausliefern, verringern die oben genannten Kontrollen das Risiko, und keine von ihnen beweist, dass ein Tool-Aufruf wirklich vom Modell stammt.

Update, 1. Oktober 2026: Auch der Router, den Sie selbst hosten, steht auf der Liste

Dieser Beitrag handelt von Routern, die jemand anderes betreibt. Die Advisory-Datenlage ergänzt die andere Hälfte. Am 1. Oktober 2026 nahm die PyPA-Advisory-Datenbank elf Einträge zu LiteLLM auf, einem Open-Source-Proxy, den Teams aus den oben genannten Gründen selbst hosten: ein Schlüssel für jedes Modell.² Keiner davon ist neu. Neun stehen seit dem 21. Juni in GitHubs Advisory-Datenbank und in der NVD, ein zehnter seit Mitte September, und derjenige, der für einen Proxy am meisten zählt, weil er die Anbieterschlüssel offenlegt, wurde am 26. August im eigenen Repository von LiteLLM veröffentlicht, mit Fixes auf PyPI seit dem 9. August; GitHub stuft ihn als Moderate ein. Es lohnt sich, sie zusammen zu lesen, wegen dessen, was sie über die Schicht aussagen, und weil jedes vor dem 9. August veröffentlichte finale Release im Bereich von CVE-2026-84377 liegt.

Zuerst sollten Sie CVE-2026-84377 lesen. Im Wortlaut des Repository-Advisorys: „Any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination they control and cause the proxy to send its own configured provider credentials to that destination.“ (Jeder authentifizierte Benutzer des LiteLLM-Proxys konnte einen ausgehenden Anbieteraufruf an ein von ihm kontrolliertes Ziel umleiten und den Proxy veranlassen, seine eigenen konfigurierten Anbieter-Credentials dorthin zu senden.) Die Ursache liegt in der Form der Prüfung: „The proxy’s request-body validation was a denylist that did not cover every sensitive parameter and did not inspect parameters nested inside other request fields.“ (Die Validierung des Anfrage-Bodys war eine Denylist, die nicht jeden sensiblen Parameter abdeckte und in anderen Anfragefeldern verschachtelte Parameter nicht prüfte.) Behoben ist das in neun Release-Linien, von 1.88.6 bis 1.96.2. Für alle, die noch nicht aktualisieren können, nennt das Advisory drei Workarounds in einem Satz: „Set general_settings.allow_client_side_credentials to false so callers cannot override connection parameters, restrict proxy keys to trusted callers, and block the affected parameters (api_base, base_url, model_list, fallbacks, provider credential fields) at a reverse proxy or API gateway.“ (Die Einstellung auf false setzen, damit Aufrufer keine Verbindungsparameter überschreiben können, Proxy-Schlüssel auf vertrauenswürdige Aufrufer beschränken und die betroffenen Parameter an einem Reverse Proxy oder API-Gateway blockieren.)² Das Erste allein genügt nicht. Im Quellcode von 1.95.0, einem betroffenen Release, wird die Prüfung des Anfrage-Bodys nur dann ganz übersprungen, wenn diese Einstellung true ist (die configurable_clientside_auth_params eines Deployments können dennoch einzelne Parameter ausnehmen); false ist also genau der Zustand, in dem sich eine Installation befindet, die die Einstellung nie angefasst hat, und die unvollständige Prüfung ist der Fehler, den das Advisory beschreibt. Die Lösung ist das Update.⁶

Ein zweiter Eintrag, CVE-2026-59823, ist derselbe Fehler im Kleinen: Die Schutzprüfung „blocks the api_base and base_url parameters but does not cover user_config“ (blockiert die Parameter api_base und base_url, deckt aber user_config nicht ab), sodass ein Aufrufer mit gültigem virtuellem Schlüssel darin ein api_base unterbringen und den Proxy auf einen beliebigen Host richten konnte. Dieser wurde in 1.83.9 gepatcht, auf PyPI seit dem 17. April; das zugehörige Advisory folgte im September.⁴

Zwei Einträge betreffen die MCP-Seite des Proxys: fehlerhafte Authentifizierung im MCP-Proxy (CVE-2026-12773, mit einem Versionsbereich, der mit einem Fix in 1.84.0 endet) und Server-Side Request Forgery über das Argument spec_path des MCP-OpenAPI-Spec-Loaders (CVE-2026-12798, erfasst als betreffend Versionen bis einschließlich 1.82.2). Die übrigen sieben betreffen die Handhabung von Admin-Schlüsseln, den SSO-Debug-Ablauf, die Invalidierung von SSO-Sitzungen, den Sitzungsablauf für generierte Schlüssel, Benutzer-Enumeration in der UI, eine Guardrail-Umgehung an asynchronen Endpunkten und die Behandlung von Machine-to-Machine-JWTs.⁵

Diese neun Einträge sind dünner als die ersten beiden. Ihre Beschreibungen tragen die Schablonenformulierungen von VulDB statt einer Darstellung durch die Maintainer, und beim MCP-Proxy-Eintrag heißt es in der Beschreibung „up to 1.59.8“ (bis 1.59.8), während der Versionsbereich einen Fix in 1.84.0 angibt.⁵ Der Eintrag zu CVE-2026-84377 hat eine eigene Unstimmigkeit: Die Repository-Seite nennt als betroffene Versionen „<1.94.0“, während die Bereiche des geprüften Eintrags die 1.96-Linie bis zu ihrem Fix in 1.96.2 umfassen.²

Prüfen Sie die Bereiche gegen das Release, das Sie betreiben, statt einer Zusammenfassung zu trauen, diese hier eingeschlossen. Jeder erfasste Bereich endet bei oder unter 1.96.2, Releases ab 1.97.0, auf PyPI seit dem 16. August, liegen also außerhalb aller elf; das aktuelle Release am 1. Oktober ist 1.103.2.⁵

Die Gefahr eines Routers liegt dort, wo die Credentials liegen, egal wer ihn betreibt. Ein Marktplatz-Router, der einen platzierten AWS-Schlüssel anfasst, und ein selbst gehosteter Proxy, den man dazu bringen kann, seine Anbieterschlüssel nach außen zu senden, sind dieselbe Gefährdung, nur aus zwei Richtungen erreicht: einmal durch den Betreiber, einmal durch jeden Mandanten mit einem virtuellen Schlüssel. Die Abwehrmaßnahmen in den Abschnitten oben setzen voraus, dass Sie der Client sind.

Für einen Proxy, den Sie selbst betreiben, kommt die Hälfte des Betreibers hinzu: Behandeln Sie jeden virtuellen Schlüssel als Zugang zu den vorgelagerten Schlüsseln dahinter, lassen Sie vom Client gelieferte Verbindungsparameter ausgeschaltet, einschließlich der configurable_clientside_auth_params pro Deployment, sofern Sie sie nicht brauchen, und stellen Sie den Proxy auf denselben Patch-Takt wie alles andere, was Geheimnisse verwahrt.

Hielt irgendjemand, dem Sie nicht voll vertrauen, einen virtuellen Schlüssel, während der Proxy ein betroffenes Release lief, rotieren Sie die Anbieterschlüssel und alle anderen auf dem Proxy konfigurierten Geheimnisse und prüfen Sie seine Logs auf ausgehende Aufrufe an Hosts, die Sie nicht konfiguriert haben; die im Advisory beschriebenen Auswirkungen umfassen „other configured secrets“ (andere konfigurierte Geheimnisse) und Anfragen an „internal services reachable from the proxy“ (vom Proxy erreichbare interne Dienste). Zwei der elf Einträge, CVE-2026-12773 im MCP-Proxy und CVE-2026-12795 im SSO-Debug-Ablauf, sind Authentifizierungsfehler in Releases unter 1.84.0; auf diesen Releases begrenzt der Besitz eines Schlüssels also womöglich nicht, wer den Proxy erreichen konnte. War er aus Netzen erreichbar, denen Sie nicht vertrauen, rotieren Sie ebenso.

Was die April-Fassung falsch machte

Die Fassung dieses Beitrags vom 10. April entstand auf Grundlage der Kurzfassung des Papers. Am 2. Oktober 2026 gegen den vollständigen Text gelesen, war sie an diesen Stellen falsch oder irreführend, alle oben korrigiert:

• AC-1.a. Ich beschrieb es als Injektion, die „only fires when the request matches a specific dependency or context“ (nur auslöst, wenn die Anfrage zu einer bestimmten Abhängigkeit oder einem Kontext passt). Tatsächlich handelt es sich um den Austausch eines Paketnamens in einem Installationsbefehl. Auslöser gehören zu AC-1.b.
• Die Abwehrmaßnahmen. Ich schrieb, „the abstract does not rank the defenses“ (die Kurzfassung bringe die Abwehrmaßnahmen in keine Rangfolge), und bot eine Rangfolge als meine Meinung an. Der Haupttext des Papers misst alle drei, nennt das Policy-Gate „the strongest immediately deployable control“ (die stärkste sofort einsetzbare Kontrolle) und berichtet, dass es in einem einfachen adaptiven Benchmark in 100 % der Proben umgangen wurde. Das hatte ich weggelassen.
• Der Rat zur Signatur. Ich riet Betreibern, Anfragen auf dem Client zu signieren und vorgelagert zu prüfen, und nannte das „the only real fix“ (die einzige echte Lösung). Das Paper fordert die umgekehrte Richtung, eine vom Anbieter signierte und vom Client geprüfte Antwort, und sagt, dass Signaturen gestohlene Geheimnisse nicht abdecken können.
• Der geleakte Schlüssel. Ich schrieb, der Schlüssel sei geleakt worden, „as if it had been exposed through a developer mistake“ (als sei er durch einen Entwicklerfehler offengelegt worden), und folgerte: „The router was a laundering layer for a stolen key.“ (Der Router war eine Geldwäscheschicht für einen gestohlenen Schlüssel.) Tatsächlich wurde er in Foren und Chatgruppen geleakt, in denen Routerbetreiber Credentials teilen, und das Paper sagt, es könne nicht immer unterscheiden, ob ein Routerbetreiber, unbeteiligte Dritte oder eine längere Relay-Kette ihn wiederverwendet haben.
• Die Credential-Zahlen. Im Antwortblock stand „17 of 28 paid routers touched planted AWS credentials“ (17 von 28 kostenpflichtigen Routern berührten platzierte AWS-Credentials), und die Beschreibung sagte, die Forscher hätten 28 Router getestet. In der Zeile für kostenpflichtige Router zeigt das Paper keinen beobachteten Credential-Missbrauch. Alle 17 Router, die AWS-Canaries nutzten, und derjenige, der ETH abzog, gehören zu den 400 kostenlosen.
• Der Rat zu Hooks. Ich empfahl PostToolUse-Hooks, die „validate response shapes“ (Antwortformen validieren). Ein PostToolUse-Hook läuft, nachdem das Tool ausgeführt wurde, und das ist für einen umgeschriebenen Befehl zu spät. Die vom Paper getestete Kontrolle ist ein Gate vor der Ausführung, in Claude Code also ein PreToolUse-Hook mit Allowlist.
• Kleinere Fehler. Das Paper hat sechs Autoren, nicht fünf. Es sagt nicht, dass ein Router „knows when it is being sampled“ (weiß, wann er stichprobenartig geprüft wird); das war meine Ausschmückung. Die Einleitung nannte das Thema „MCP trust chains“ (MCP-Vertrauensketten), und das Paper untersucht Router, nicht MCP. Den Silent-Egress-Beitrag beschrieb ich als Text über Tool-Beschreibungen, obwohl er von Anweisungen handelt, die in abgerufenen Inhalten versteckt sind.

FAQ

Was ist in diesem Zusammenhang ein LLM-API-Router?

Ein Dienst, der Anfragen in einem einheitlichen, meist OpenAI-kompatiblen Format annimmt, einen vorgelagerten Modellanbieter auswählt und die Antwort zurückgibt. Er ist ein Proxy auf Anwendungsebene mit Klartextzugriff auf jede Anfrage und jede Antwort.¹

Schützt mich TLS vor einem bösartigen Router?

Nein. Der Client konfiguriert den Router als seinen Endpunkt, also terminiert der Router die TLS-Sitzung des Clients und öffnet eine eigene nach oben. TLS schützt jede Teilstrecke, aber nicht die Nutzdaten vor dem Router.¹

Wie würde ich einen Router erkennen, der Tool-Aufrufe umschreibt?

Durch Testen nicht zuverlässig. Zwei Router in der Studie schleusten erst nach 50 Anfragen oder nur bei automatisch freigegebenen Sitzungen an Rust- oder Go-Projekten ein, und das Paper folgert, dass „no fixed-length client test can guarantee that the router is benign“ (kein clientseitiger Test fester Länge garantieren kann, dass der Router harmlos ist). Eine Fail-closed-Allowlist für Shell-Befehle und Paketinstallationen blockiert die einfachen Fälle, und das Paper zeigt, dass ein Angreifer, der die Abwehr kennt, an ihr vorbeikommt.¹

Hilft ein PreToolUse-Hook?

Ja, als Policy-Gate. Der Hook sieht den Tool-Aufruf, den der Client erhalten hat, also den umgeschriebenen, falls ein Router ihn umgeschrieben hat, und kann Befehle blockieren, die von nicht gelisteten Domains laden oder nicht gelistete Pakete installieren. Ob der Aufruf dem entspricht, was das Modell erzeugt hat, kann er nicht erkennen.¹³

Ich nutze Claude Code direkt gegen api.anthropic.com. Bin ich betroffen?

Nicht von den Router-Angriffen in diesem Paper, denn es gibt keine Zwischeninstanz. Leiten Sie Claude Code aus irgendeinem Grund über einen Proxy, etwa ein Unternehmens-Gateway oder einen Modell-Aggregator, hat dieser Proxy dieselbe Position.

Was ist mit OpenRouter, LiteLLM oder anderen bekannten Aggregatoren?

Das Paper misst 28 kostenpflichtige Router von drei Marktplätzen und 400 kostenlose Router, die überwiegend auf zwei Open-Source-Vorlagen beruhen. LiteLLM und OpenRouter nennt es als Hintergrund und testet sie nicht. Der strukturelle Punkt gilt für jeden Router: Er kann den Datenverkehr lesen und umschreiben, und Bekanntheit ist eine andere Eigenschaft als Integrität. Für einen Proxy, den Sie selbst hosten, behandelt das Update vom 1. Oktober oben elf LiteLLM-Advisories.

Wem gehörten die 401 automatisch freigegebenen Sitzungen?

Dritten, deren Datenverkehr die Köder-Relays der Forscher erreichte. Wenn Sie automatisch freigegebene Agentensitzungen über einen Router laufen lassen, den Sie nicht gebaut haben, hören Sie damit auf, rotieren Sie jedes Credential, das ihn passiert hat, und prüfen Sie die Sitzungsprotokolle auf Tool-Aufrufe, die Sie nicht erwartet haben.

Quellenangaben