Wenn der KI-Agent zum privilegierten Insider wird: Drei aktuelle CVEs in LiteLLM, Flowise und MS-Agent

TL;DR — die 90-Sekunden-Zusammenfassung

CVE-2026-42208 (CVSS 9.3)

SQL-Injection im LiteLLM-Gateway via API-Key-Verifikation — ein hochprivilegiertes System gegenüber Provider-Tokens

CVE-2026-41264

Indirekte Prompt-Injection im Flowise CSV-Agent — bösartig formatierte CSV führt zu RCE

CVE-2026-2256

ModelScope MS-Agent führt beliebige OS-Befehle aus — ausgelöst durch konsumierte Inhalte, nicht durch direkten User-Input

Lethal Trifecta

Tool-Zugriff + externe Inhalts-Konsumtion + privilegierter Lauf — jede Kombination ohne Policy-Layer ist exploitable

Architektur-Schwelle

Vier Prinzipien: Policy-Engine zwischen Modell und Werkzeug, Minimal-Berechtigungen mit kurzlebigen Tokens, strukturelle Pre-Processing von passiven Quellen, Audit-Log mit Herkunfts-Tag

Wer ist gefordert

jeder Mittelstand mit produktivem Agenten-Einsatz — Tool-Inventur und Token-Lifetime-Disziplin sind nicht optional

 

Was ist das Problem?

Wer in den letzten Monaten ernsthaft begonnen hat, KI-Agenten in Geschäftsprozesse zu integrieren, kennt das ungute Gefühl: Ein LLM, das selbständig Tools aufruft, Datenquellen liest und Entscheidungen trifft, ist im Sicherheitsmodell näher an einem hochprivilegierten Service-Account als an einem Chatbot. Drei CVEs aus dem Frühjahr 2026 machen das schmerzhaft konkret.

CVE-2026-42208 — SQL-Injection in LiteLLM

CVE-2026-42208 (CVSS 9.3) trifft LiteLLM, das verbreitete Open-Source-Gateway, das Anfragen über verschiedene LLM-Provider routet. Die Lücke liegt in der API-Key-Verifikation: Eine vom Nutzer gelieferte Schlüsselzeichenfolge wurde direkt in einen SQL-Query konkateniert statt parametrisiert. Klassische SQL-Injection in einem System, das selbst hochprivilegiert auf API-Keys mehrerer Provider zugreift.

CVE-2026-41264 — Indirekte Prompt-Injection in Flowise

CVE-2026-41264 betrifft den CSV-Agent in FlowiseAI. Eine bösartig formatierte CSV-Datei löst eine indirekte Prompt-Injection aus, die in der Folge zur Remote-Code-Ausführung führt. Das Tückische: Die schädliche Nutzlast kommt nicht aus direktem User-Input, sondern aus einem vermeintlich passiven Dokument, das der Agent verarbeitet.

CVE-2026-2256 — Shell-Game in MS-Agent

CVE-2026-2256 in ModelScope MS-Agent geht einen Schritt weiter. Ein Angreifer kann den Agenten so manipulieren, dass dieser beliebige Betriebssystem-Befehle ausführt — ausgelöst nicht durch direkten Nutzerzugriff, sondern durch Inhalte, die der Agent im regulären Betrieb verarbeitet. Eine Konstellation, die Sicherheitsforscher mittlerweile als lethal trifecta bezeichnen: ein Agent, der Tool-Zugriff hat, externe Inhalte konsumiert und privilegiert läuft.

Wir bauen KI-Agenten für Mittelständler, die ohne diese Werkzeuge in den nächsten 24 Monaten ins Hintertreffen geraten — unter einer Annahme, die wir in jedem Projekt-Setup-Workshop durchziehen: Jede Agent-Antwort ist potenziell von außen beeinflusst. Daraus folgen die Architektur-Prinzipien, die wir in diesem Beitrag beschreiben.

Auswirkungen: warum diese drei CVEs strukturell zusammengehören

Einzeln betrachtet wirken die Lücken wie typische Bugs in jungen Frameworks. Im Zusammenspiel ergeben sie ein klares Bild davon, wo Agent-Architekturen heute systematisch brüchig sind.

Die Vertrauensgrenze ist verschoben

Bei klassischen Webanwendungen ist klar: Eingaben von außen sind unsicher. Bei Agenten gilt dasselbe für jedes Dokument, jede Mail, jede CSV, jeden Slack-Thread, den der Agent als Kontext lädt. Inhalt wird zu Anweisung, sobald er ins Modell fließt. Die OWASP-Listen für LLM-Anwendungen führen Prompt Injection deshalb seit 2026 als LLM01.

Tool-Zugriff verstärkt die Hebelwirkung

Eine erfolgreiche Prompt-Injection ist nicht mehr nur eine Manipulation der Antwort, sondern aktiviert Werkzeuge, die auf Datenbanken, APIs, das Dateisystem oder externe Dienste zugreifen. Was bei OpenClaw als Slack-Integration auftrat, wird bei MS-Agent zur OS-Befehlsausführung.

Die Identität ist unscharf

Wenn ein Gateway wie LiteLLM kompromittiert wird, sind nicht nur die eigenen Daten betroffen, sondern alle nachgelagerten Provider-Keys. Eine kompromittierte Agent-Komponente kann Tokens stehlen, mit denen wiederum andere Systeme weitere Aktionen auslösen.

Wer ist betroffen?

Drei Punkte, die wir in jedem Pre-Audit für Agent-Stacks abklopfen.

Privilegien akkumulieren sich unbemerkt

Ein Agent beginnt typischerweise klein — ein Datentopf, ein Tool. Mit jedem Sprint kommen Werkzeuge, Datenquellen und Berechtigungen dazu. Sechs Monate später ist aus einem freundlichen Helfer ein überprivilegierter Service geworden, dessen Berechtigungs-Inventar niemand mehr im Kopf hat. Genau hier zerfallen die drei CVEs in voller Höhe.

Indirekte Eingaben werden im Audit selten geprüft

CSV, PDF, E-Mail-Anhang, Webseite, Konfigurationsdatei — alles, was der Agent als Kontext lädt, ist Angriffsfläche. Ohne strukturiertes Pre-Processing und Sandboxing bleibt diese Fläche unsichtbar, bis ein Vorfall sie sichtbar macht.

Identitäten sind nicht segmentiert

Wenn der Agent mit demselben Long-Lived-Token arbeitet, das auch andere Services nutzen, ist eine erfolgreiche Ausnutzung kein lokales Problem mehr. Sie reicht potenziell durch die gesamte Kundenlandschaft. Ein einziges kompromittiertes PAT in einem CI-Runner zieht sich wie bereits beim npm-EVM-Cluster dokumentiert durch jede Workstation, die diesen Token gelesen hat.

Mitigation: vier Architektur-Prinzipien

Wir folgen vier Architektur-Prinzipien, die wir in jedem Agent-Projekt durchziehen. Sie sind bewusst unspektakulär und greifen in Summe.

1. Trennung von Modell und Tool-Zugriff durch eine Policy-Engine

Ein Agent, der Tools aufruft, tut das nicht im selben Prozess, in dem er die Prompt verarbeitet. Zwischen Modell und Werkzeug steht eine kleine Policy-Engine — sei es nur ein Allowlist-Filter —, die verhindert, dass ein erfolgreich injizierter Befehl direkt zur Aktion wird. Praktisch ist das ein eigener Service, der Tool-Aufrufe abnimmt, gegen eine Allowlist prüft, Parameter validiert und erst dann ausführt.

2. Minimal-Berechtigungen je Agent, kurzlebige Tokens

Service-Accounts mit Read-Only auf eng definierte Datentöpfe statt eines „omniscient“ API-Keys. Wenn der Agent nur sechs Tools braucht, dürfen es keine sieben sein. Tokens sind kurzlebig, idealerweise OIDC-basiert, ohne Long-Lived-PATs. Das ist exakt dieselbe Disziplin, die wir in unserem MCP-Server-Beitrag für Tool-Loader beschreiben.

3. Verifikation von Eingaben aus passiven Quellen

CSV, PDF, E-Mail-Anhang, Webseite, Konfigurationsdatei — alles wird vor der Modell-Verarbeitung strukturell geprüft. Pre-Processing mit Schemakontrollen, Sandboxing, im Zweifel ein zweites Modell, das nur die Aufgabe hat, verdächtige Anweisungen zu erkennen. Bei CSV-Eingaben heisst das konkret: Spaltentypen prüfen, Sonderzeichen filtern, Maximallängen erzwingen — bevor der Inhalt das Modell erreicht.

4. Audit-Log mit Herkunfts-Tag pro Kontext

Jeder Kontext, der ins Modell gelangt, trägt ein Herkunfts-Tag mit. Im Audit-Log ist nachvollziehbar, woher eine Anweisung kam und welches Werkzeug daraufhin aufgerufen wurde. Das ist die Voraussetzung dafür, einen Vorfall überhaupt rekonstruieren zu können. Ohne Herkunfts-Tags ist ein Agent-Audit-Log eine Liste von Antworten ohne Kausalität.

Detection und Prüfung — wie Sie eine Lethal Trifecta erkennen

Ein Agent ist dann unkritisch, wenn höchstens zwei der drei Trifecta-Bedingungen erfüllt sind. Fünf Kernfragen, die wir in jedem Pre-Audit stellen, um die dritte Bedingung zu finden, bevor ein CVE sie offenlegt:

• Welche Tools darf jeder produktive Agent aufrufen — dokumentiert oder vermutet? Wenn die Liste in keinem Code-Review oder Whiteboard auftaucht, ist sie de facto unbegrenzt.
• Welche passiven Quellen liest der Agent? E-Mail-Postfach, Zendesk-Ticket, Confluence-Page, SharePoint-Ordner, S3-Bucket — alles, was nicht der direkte User-Prompt ist.
• Welche Tokens hat der Agent zur Laufzeit — Long-Lived-PAT, OIDC-Service-Account, AWS-Role, Datenbank-Credential? Für jeden Token: wie alt, wie viele Scopes, wer kann den noch lesen?
• Existiert ein Audit-Log, das die Verbindung zwischen welche Quelle hat eine Anweisung erzeugt und welches Tool wurde daraufhin aufgerufen sichtbar macht? Falls nein: jeder Vorfall ist im Nachhinein unrekonstruierbar.
• Wann wurde der Agent zuletzt auf neuere CVEs in seinen Frameworks geprüft? npm audit, pip-audit und ein manueller Vergleich der Pinned-Versionen mit OSV.dev sind nicht optional.

Ein schneller Quick-Check, mit dem wir vor jedem Architektur-Review beginnen:

grep -rE "(litellm|flowise|ms-agent|crewai|langgraph|autogen)" \
  --include=requirements.txt --include=package.json \
  --include=pyproject.toml --include=Pipfile

Was so auftaucht, bekommt ein Token-Inventar, ein Tool-Inventar und eine Quellen-Liste. Das ist die Basis für die folgende Betreiber-Entscheidung.

Betreiberempfehlung

Was für welchen Agent-Stack konkret operativ stehen sollte — abhängig vom heutigen Reifegrad.

• Wenn Ihr Agent heute Long-Lived-PATs nutzt und passive Quellen ungeprüft konsumiert — dann sind kurzlebige Tokens über OIDC und ein CSV/PDF-Pre-Processor die zwei nächsten Sprints. Vorher keine weiteren Tools an den Agent anschließen.
• Wenn Sie LiteLLM als zentrales Gateway nutzen — dann ist das Update auf 1.83.10-stable in dieser Woche und ein internes Re-Audit der API-Key-Verifikation Pflicht. LiteLLM ist Single-Point-of-Failure für alle Provider-Keys.
• Wenn Sie Flowise oder einen anderen No-Code-Agent-Builder im Einsatz haben — dann ist die Disziplin, jeden CSV- oder Dokument-Input über einen Sanitizer laufen zu lassen, wichtiger als das Patchen der einzelnen CVE. Die nächste indirekte Injection kommt sicher.
• Wenn Ihr Agent-Stack im MS-Agent-Umfeld oder ähnlich tief in OS-Nähe läuft — dann Container-Isolation mit minimalen Capabilities und Read-Only-Root-FS als Standard, nicht als Option. Sandboxing ist die letzte Verteidigungslinie.
• Wenn Ihr Audit-Log heute keine Herkunfts-Tags führt — dann ist der Nachbau dieser Funktion vor dem nächsten neuen Tool-Onboarding der größte Hebel. Ohne Herkunft kein Vorfall-Reconstruct, ohne Reconstruct keine Verbesserung.

Querverweise: der MCP-Server-Beitrag für Tool-Loader-Disziplin, der Semantic-Kernel-Beitrag für Framework-Vergleich, und der KI-Security-Audits-Beitrag für die Einbindung in Release-Disziplin.

Fazit

Die meisten Agent-Stacks, die wir im Review sehen, haben einzelne dieser Bausteine. Selten alle. Entweder es gibt eine Policy-Engine, aber Long-Lived-Tokens. Oder das Token-Management ist gut, aber CSVs gehen ungeprüft ins Modell. Oder beides ist sauber, aber das Audit-Log endet auf Modell-Ebene und sagt nichts darüber, welche externe Quelle eine bestimmte Antwort beeinflusst hat.

Die Frage lautet nicht, ob LiteLLM in Ihrem Stack auf 1.83.10-stable aktualisiert ist. Sie lautet, ob ein vergleichbarer Vorfall in einer beliebigen anderen Komponente Ihres Agent-Stacks bemerkt würde — und wie viele Tools, Datenquellen und Tokens davon in einer einzigen kompromittierten Stunde betroffen wären.

Eine längere Aufarbeitung mit Architektur-Skizzen unserer Policy-Engine, einem Beispiel für Herkunfts-Tags im Audit-Log und einer Einordnung, warum wir bei produktiven Agenten konsequent ohne Long-Lived-PATs arbeiten, findet sich unter ole-hartwig.eu.