Drei KI-Plattformen kompromittiert: Ein Gateway öffnet den Weg zu allen Schlüsseln

Microsoft dokumentierte am 26. August 2026 drei getrennte Kompromittierungen von LiteLLM, RAGFlow und Kestra. Die Untersuchung von Microsoft Security Research belegt je nach Plattform Schlüsseldiebstahl, Persistenz, Datenzugriffe und Kryptomining aus dem Kontext zentraler KI-Dienste.

Betroffen waren drei unterschiedliche Kontrollpunkte: ein LiteLLM-Gateway, eine RAGFlow-Installation und eine Kestra-Workflow-Umgebung. Eine am 27. August erschienene Einordnung von CISO Voice bestätigt die drei Fälle und ihre privilegierten Rollen, weist aber auch darauf hin, dass die genannten Schwachstellen bei LiteLLM nur relevante Angriffspfade und bei RAGFlow gar keine bestätigte Ursache darstellen.

Drei Rollen, drei beobachtete Angriffspfade

Bei LiteLLM begann die Folgeaktivität im Prozesskontext des Gateways. Als wahrscheinlicher Zugang gilt eine verwundbare, offen erreichbare Gateway-Oberfläche; die Kette aus CVE-2026-42271 und CVE-2026-48710 passt technisch zu den Beobachtungen, ist für den konkreten Einbruch jedoch nicht abschließend bewiesen. Anschließend wurden die Prozessumgebung und eine PostgreSQL-Datenbank nach Provider-Schlüsseln, Master Key, virtuellen Schlüsseln, Passwörtern und Verbindungsdaten durchsucht.

Im RAGFlow-Fall ging einer späteren Codeausführung eine mögliche SSRF-ähnliche Erkundung voraus. Der genaue Einstieg blieb ungeklärt. Nach der Kompromittierung veränderten die Angreifer den Start- beziehungsweise Importpfad und platzierten einen Python-Hook in dem Ablauf, über den Mandanten LLM-Anbieter konfigurieren. So konnten nach der Infektion neu eingetragene Provider-Schlüssel, Modellnamen und Endpunktdaten abgefangen werden.

Bei Kestra wird CVE-2026-49869, eine Umgehung der Authentifizierung, mit hoher Wahrscheinlichkeit als Einstieg bewertet. Ein bösartiger Workflow löste Shell-Befehle im Worker-Kontext aus. Danach griffen die Angreifer auf einen eingebundenen Docker-Socket zu, untersuchten Umgebungswerte erreichbarer Container, installierten XMRig und speicherten gesammelte Ausgaben über Kestras Key-Value-Schnittstelle.

Warum ein Gateway den Weg zu allen erreichbaren Schlüsseln öffnet

Das besondere Risiko entsteht durch die Konzentration von Vertrauen. Ein LiteLLM-Gateway kann Schlüssel mehrerer Modellanbieter, den eigenen Master Key, virtuelle Schlüssel, Datenbankverbindungen, Routingdaten und Mandantenrichtlinien in einem Laufzeitkontext halten oder abrufen. Eine Übernahme erreicht damit potenziell nicht nur die Anwendung selbst, sondern sämtliche Anbieter- und Backend-Zugänge, die genau dieses Gateway verwaltet.

Im untersuchten Fall las Schadcode die Umgebung des Gateway-Prozesses aus und verwendete die dort gefundene Datenbankverbindung für den Zugriff auf LiteLLM-Tabellen. Erreichbar waren unter anderem Modellkonfigurationen, Provider-Endpunkte und proxyseitig ausgegebene virtuelle Schlüssel. Hinzu kamen ein bei einem Dienstkonto hinterlegter SSH-Schlüssel, Tarnnamen für Programme und weitere Mechanismen für dauerhaften Zugriff.

„Alle Schlüssel“ bezeichnet deshalb keinen festen, bei jeder Installation identischen Datensatz. Gemeint sind alle Geheimnisse, die das kompromittierte Gateway aufgrund seiner konkreten Konfiguration erreichen kann. Der mögliche Schaden wächst mit der Zahl angebundener Anbieter, Mandanten und Backends sowie mit den Rechten des Gateway-Dienstkontos.

Die Risikomatrix der drei Plattformrollen

Die Fälle unterscheiden sich bei den gefährdeten Geheimnissen und den Spuren, die nach einer Kompromittierung zuerst relevant werden:

• LiteLLM als Gateway: Erreichbar waren Provider-Schlüssel, Master Key, virtuelle Schlüssel, UI-Zugangsdaten und PostgreSQL-Verbindungen. Beobachtet wurden das Auslesen von Laufzeit und Datenbank, Exfiltration, SSH-Persistenz und Mining. Zu prüfen sind deshalb Prozessumgebung, Proxy-Datenbank, ausgehende Verbindungen, Cron-Einträge und autorisierte SSH-Schlüssel.
• RAGFlow als RAG-Plattform: Der implantierte Hook zielte auf neu konfigurierte LLM-Zugangsdaten und zugehörige Metadaten. Eine sofortige Schlüsselrotation allein kann wirkungslos sein, wenn die manipulierte Anwendung auch die Ersatzschlüssel abfängt. Vor der Rotation müssen Startdateien, Importpfade und persistente Container-Dateisysteme bereinigt werden.
• Kestra als Orchestrator: Workflow-Ausführung und Docker-Zugriff machten Umgebungswerte erreichbarer Container zugänglich, darunter potenziell Cloud-Schlüssel, Datenbankpasswörter und API-Tokens. Relevante Spuren sind unbekannte Workflows, Shell-Kindprozesse, Docker-Socket-Zugriffe, Miner-Artefakte und ungewöhnliche Daten im Key-Value-Speicher.

Damit reicht eine Suche nach bekannten CVE-Nummern nicht aus. Für RAGFlow ist die konkrete Eintrittsstelle nicht bekannt, während die Manipulation des Anwendungspfads deutlich belegt ist. Bei LiteLLM und Kestra gelten bestimmte Schwachstellen als wahrscheinliche Erklärung, nicht als universeller Nachweis für jede kompromittierte Installation.

Honeypots zeigen parallele Angriffe auf LiteLLM

Die drei Fallstudien werden durch breitere Angriffsdaten ergänzt, ohne dass damit eine gemeinsame Kampagne belegt wäre. Die am 27. August veröffentlichten 90-Tage-Beobachtungen von Wiz Threat Research zeigen anhaltende, auf konkrete KI-Dienste zugeschnittene Angriffe: In LiteLLM-Honeypots wurden unter anderem eine Authentifizierungsumgehung, Befehlsinjektion und das Auslesen des Master Key direkt aus dem Python-Prozessspeicher beobachtet.

Vor einem weiteren Missbrauch ermittelten Angreifer außerdem, welche Backend-Modelle über den Proxy erreichbar waren. Diese Kenntnis erlaubte die Entscheidung, ob sich ein Schlüssel stehlen, das Inferenzkontingent missbrauchen oder das Ziel verwerfen ließ. Das spricht für plattformspezifische Nachausnutzung statt ausschließlich generischer Angriffe auf beliebige Linux-Server.

Für exponierte Installationen ergibt sich daraus eine abgestufte Reaktion: Verwaltungsoberflächen vom öffentlichen Internet trennen, betroffene Versionen aktualisieren und unerwartete Shell- oder Interpreter-Prozesse unterhalb der KI-Anwendung untersuchen. Ausgehende Verbindungen und die Rechte von Datenbank-, Cloud- und Docker-Zugängen sollten begrenzt werden. Schlüssel sind erst nach der Entfernung möglicher Hooks und Persistenzmechanismen zu rotieren, damit bereinigte Zugangsdaten nicht erneut abfließen.

Belegt sind drei getrennte Kompromittierungen verschiedener KI-Plattformrollen sowie parallele aktive Angriffe auf LiteLLM-Honeypots. Offen bleiben ein möglicher gemeinsamer Urheber, ein Zusammenhang der Fälle als einheitliche Kampagne und der genaue Einstieg bei RAGFlow. Sicher ist dagegen, dass Gateways, RAG-Dienste und Orchestratoren wegen ihrer gebündelten Schlüssel und Ausführungsrechte wie privilegierte Kontrollpunkte behandelt werden müssen.

Lesen Sie auch:

• LibreOffice 26.8 verbessert den Blocksatz – und verzichtet bewusst auf KI
• Neno sammelt 6,6 Millionen Euro ein: KI-Buchhaltung zielt auf Europas KMU
• Substack oder Patreon: Die gleiche Provision, aber ein anderer Engpass