Elf Uhr neununddreißig Weltzeit, 21. Oktober 2026: Zu diesem Zeitpunkt lud ein Angreifer eine manipulierte Version von LiteLLM auf PyPI hoch. Weniger als zwei Stunden später begann das Aufräumen, doch wer in diesem Fenster installierte, hatte womöglich bereits einen Credential-Stealer und eine Backdoor auf seinen Systemen. Der LiteLLM Supply Chain Angriff zeigt erneut, wie verwundbar KI-Infrastruktur gegenüber gezielten Kompromittierungen der Lieferkette ist.
LiteLLM ist ein weitverbreitetes Open-Source-Gateway von BerriAI, das Entwicklern einen einheitlichen Zugriff auf verschiedene LLM-Provider wie OpenAI oder Anthropic ermöglicht. Genau diese zentrale Stellung in vielen KI-Pipelines macht das Projekt zu einem attraktiven Ziel, und genau deshalb verdient der aktuelle Vorfall die volle Aufmerksamkeit von Entwicklern und Sicherheitsverantwortlichen.
Inhaltsverzeichnis
Key Takeaways
- Version 1.107.0 von LiteLLM wurde am 21. Oktober 2026 auf PyPI mit Schadcode in allen sieben Wheel-Dateien veröffentlicht.
- Auch mehrere Docker-Images auf GHCR und Docker Hub waren betroffen, bevor sie entfernt oder zurückgesetzt wurden.
- Der Schadcode bestand aus drei Dateien: einem automatischen Loader (cook.pth), einem Credential-Stealer (cook.py) und einer Backdoor mit Nachladefunktion (sitecustomize.py).
- Gestohlen wurden unter anderem Cloud-Zugangsdaten, API-Keys, SSH-Schlüssel und Browser-Logins, verschlüsselt und an eine externe Domain gesendet.
- Es ist bereits der zweite schwere Sicherheitsvorfall bei LiteLLM innerhalb von sieben Monaten.
Was ist beim LiteLLM Supply Chain Angriff passiert
Am 21. Oktober 2026 veröffentlichte ein Unbekannter die Version 1.107.0 des LiteLLM-Pakets auf PyPI. Die Veröffentlichung erfolgte um 11:39 UTC. Alle sieben Wheel-Dateien dieser Version, also die vorkompilierten Pakete für Windows, Linux und macOS, enthielten Schadcode. Damit war praktisch jeder betroffen, der in diesem Zeitraum das Paket installierte, unabhängig vom genutzten Betriebssystem.
Parallel dazu waren auch Docker-Images kompromittiert. Betroffen waren:
- ghcr.io/berriai/litellm
- litellm-database
- litellm-non_root
- docker.io/litellm/litellm
Dies betraf die Tags v1.107.0, latest, main-latest und main-stable. Wer in diesem Zeitraum eines dieser Images zog, konnte ebenfalls kompromittierte Software erhalten haben.
Die gute Nachricht: Die Reaktionszeit war vergleichsweise kurz. PyPI quarantänierte die bösartige Version gegen 13:20 bis 13:23 UTC. Die GHCR-Tags blieben bis 13:51 UTC verfügbar, auf Docker Hub wurden die Tags erst um 14:20 UTC entfernt beziehungsweise auf saubere Images zurückgesetzt. Insgesamt war das Schadpaket also rund zweieinhalb bis drei Stunden aktiv erreichbar, eine Zeitspanne, die bei der weiten Verbreitung von LiteLLM in CI/CD-Pipelines durchaus ausreicht, um zahlreiche Systeme zu infizieren.
"Die Untersuchung des genauen Einfallswegs läuft noch", erklärte LiteLLM-Sicherheitschef Oliver Jensen, ein Hinweis darauf, dass die vollständige Aufklärung des LiteLLM Supply Chain Angriffs noch Zeit braucht.
Technische Details zum LiteLLM Supply Chain Angriff
Der eingeschleuste Schadcode bestand aus drei zusammenwirkenden Dateien. Diese Struktur ist bemerkenswert, weil sie zeigt, wie gezielt der Angriff konstruiert wurde.
Die drei Schadkomponenten
| Datei | Funktion |
|---|---|
| cook.pth | Startet automatisch beim Python-Start den Import von "cook", ohne jede weitere Nutzeraktion |
| cook.py | Der eigentliche Credential-Stealer, intern "privcollect" genannt |
| sitecustomize.py | Ein Remote-Access-Trojaner, der eine dauerhafte Hintertür einrichtet |
Besonders tückisch ist die Datei cook.pth. Python lädt.pth-Dateien automatisch beim Interpreter-Start, sodass der Schadcode ohne jegliches Zutun des Nutzers ausgeführt wird, ein simples "pip install" reicht bereits aus, um die Infektion in Gang zu setzen.
Der Credential-Stealer im Detail
Die Datei cook.py arbeitet mit rund 16 Modulen, die gezielt sensible Daten absammeln. Dazu zählen:
- Browser-Logins und Cookies aus Chrome, Firefox, Edge und Safari
- AWS-Zugangsdaten aus dem Verzeichnis ~/.aws/
- Umgebungsvariablen des Systems
- Instance-Metadaten von EC2 und ECS
- Google-Cloud-Service-Account-Keys
- Azure-CLI-Tokens
- API-Keys von Anbietern wie OpenAI, Anthropic, Cohere und weiteren LLM-Diensten
- SSH- und GPG-Schlüssel
- Shell-Historien
Die gesammelten Daten werden anschließend mit AES-256-CBC verschlüsselt. Der dafür verwendete Schlüssel wird wiederum mit RSA-4096 gesichert, bevor die Daten per HTTP-POST an die Domain litellm[.]dev/healthcheck übertragen werden. Die Wahl dieses Domainnamens ist kein Zufall: Er ähnelt stark dem Namen des Originalprojekts und sollte offensichtlich Verdacht vermeiden, falls Netzwerkverkehr überhaupt auffiel.
Die Backdoor-Komponente
Noch gefährlicher als der reine Datendiebstahl ist die dritte Komponente: sitecustomize.py. Diese Datei startet einen Hintergrund-Daemon, der stündlich einen sogenannten Dead-Drop auf GitHub (github.com/letters9813) abfragt. Über diesen Kanal kann der Angreifer beliebigen Python-Code nachladen und auf dem kompromittierten System ausführen. Das bedeutet: Selbst nach dem ersten Datendiebstahl bleibt das System dauerhaft fernsteuerbar, solange die Backdoor aktiv ist.
Was beim LiteLLM Supply Chain Angriff gestohlen wurde
Die Bandbreite der abgegriffenen Daten ist ungewöhnlich umfassend. Es handelt sich nicht um einen simplen Passwort-Diebstahl, sondern um einen systematischen Griff nach praktisch allen relevanten Zugangsdaten eines Entwickler- oder Serversystems:
- Cloud-Zugänge: AWS, Google Cloud und Azure sind allesamt betroffen, was im schlimmsten Fall weitreichenden Zugriff auf komplette Cloud-Infrastrukturen ermöglicht.
- KI-Provider-Keys: Gerade weil LiteLLM als Gateway zu Diensten wie OpenAI und Anthropic fungiert, lagen auf vielen Systemen genau die API-Keys, die für den täglichen Betrieb solcher Gateways benötigt werden.
- Zugriffsschlüssel für Entwicklerinfrastruktur: SSH- und GPG-Schlüssel erlauben potenziell Zugriff auf Code-Repositories, Server und Signaturen.
- Browserdaten: Gespeicherte Logins und Cookies können für weitere Angriffe auf andere Dienste missbraucht werden.
Für Unternehmen bedeutet dies: Ein erfolgreicher Diebstahl kann sich nicht auf ein System beschränken, sondern als Sprungbrett für weitere Angriffe in der Cloud-Infrastruktur oder bei Drittanbietern dienen.
Sofortmaßnahmen nach dem LiteLLM Supply Chain Angriff
Wer LiteLLM im betroffenen Zeitfenster installiert oder aktualisiert hat, sollte umgehend handeln. Die folgenden Schritte gelten als notwendig, nicht optional:
- Betroffene Deployments sofort stoppen. Laufende Instanzen mit der Version 1.107.0 oder den genannten Docker-Tags dürfen nicht weiterlaufen.
- Systeme isolieren. Keine weiteren Verbindungen zulassen, bis die Analyse abgeschlossen ist.
- Aus sauberen Backups neu aufbauen. Es reicht ausdrücklich nicht aus, lediglich das Package-Verzeichnis zu löschen. Startdateien wie cook.pth oder der Loader können im System zurückbleiben und bei nächstem Python-Start erneut aktiv werden.
- Alle potenziell exponierten Zugangsdaten rotieren. Dazu zählen AWS-, GCP- und Azure-Zugänge, API-Keys der LLM-Provider, SSH- und GPG-Schlüssel sowie Browser-Logins, die auf dem betroffenen System gespeichert waren.
- Systeme auf bekannte Indikatoren prüfen. Konkret auf die Dateien cook.pth, cook.py und sitecustomize.py sowie auf die genannten Image-Hashes der betroffenen Docker-Images.
- Prüfung ohne Risiko durchführen. Wichtig: Die Prüfung sollte nicht erfolgen, indem Python oder pip innerhalb der möglicherweise verseuchten Umgebung selbst gestartet wird, da dies den Schadcode erneut auslösen kann.
Als saubere Rückkehrversion empfiehlt sich LiteLLM 1.106.2, die letzte bekannte unbetroffene Version vor dem Angriff.
Checkliste für DevOps-Teams:
- Versionsstand aller LiteLLM-Installationen geprüft
- Docker-Image-Tags mit Hashes abgeglichen
- IOC-Scan ohne Ausführung von Python in der betroffenen Umgebung durchgeführt
- Betroffene Secrets identifiziert und Rotation eingeleitet
- Systeme aus sauberem Backup neu aufgesetzt
- Netzwerk-Logs auf Verbindungen zu litellm[.]dev und github.com/letters9813 geprüft
Einordnung: Bereits der zweite Vorfall binnen sieben Monaten
Der aktuelle LiteLLM Supply Chain Angriff ist kein Einzelfall. Erst wenige Tage zuvor sorgten eine kritische PHP-Sicherheitsluecke und eine Node.js-Sicherheitsluecke mit Brotli-RCE fuer aehnliche Notfall-Patches in der Entwickler-Community. Im März 2026 war LiteLLM bereits einmal Ziel einer Kompromittierung, bekannt als TeamPCP-Vorfall. Laut Einschätzungen von CloudSEK waren davon möglicherweise mehr als 2.500 Organisationen und rund 434.000 CI/CD-Pipelines betroffen. Dass innerhalb von nur sieben Monaten zwei schwerwiegende Sicherheitsvorfälle dasselbe Projekt treffen, wirft ernsthafte Fragen zur Absicherung der Build- und Release-Pipelines auf.
Für Entwickler und Sicherheitsteams bedeutet dies vor allem eines: Vertrauen in ein einzelnes Open-Source-Projekt, auch wenn es weit verbreitet und etabliert ist, ersetzt keine eigene Prüfung. Gerade bei Komponenten, die tief in produktive Pipelines eingebunden sind und Zugriff auf sensible Zugangsdaten haben, sollte es Standard sein, Versionsupdates nicht blind zu übernehmen, sondern über Staging-Umgebungen und Integritätsprüfungen laufen zu lassen.
Fazit und nächste Schritte
Der LiteLLM Supply Chain Angriff vom 21. Oktober 2026 zeigt eindrücklich, wie schnell aus einer kompromittierten Paketquelle eine ernsthafte Sicherheitskrise entstehen kann. Innerhalb weniger Stunden wurden Zugangsdaten zu Cloud-Diensten, LLM-Providern und Entwicklerinfrastruktur potenziell abgegriffen, verschlüsselt und über eine täuschend echt wirkende Domain exfiltriert. Die zusätzliche Backdoor-Funktion macht den Vorfall noch gravierender, da betroffene Systeme auch nach dem ersten Datendiebstahl fernsteuerbar bleiben können.
Entwickler und DevOps-Teams, die LiteLLM einsetzen, sollten umgehend prüfen, ob ihre Systeme im betroffenen Zeitfenster aktualisiert wurden. Im Zweifel gilt: lieber einmal zu viel ein System neu aufsetzen und Zugangsdaten rotieren, als ein kompromittiertes System unbemerkt weiterlaufen zu lassen. Angesichts des bereits zweiten Vorfalls binnen sieben Monate ist zudem eine grundsätzliche Überprüfung der eigenen Lieferketten-Sicherheit bei KI-Infrastruktur ratsam, unabhängig davon, welches Gateway oder Framework konkret im Einsatz ist.
