LiteLLM 1.107.0: Zwei Stunden lang ein Credential-Stealer auf PyPI
Die wichtigsten Fakten
- Am 21. Oktober schob eine kompromittierte Release-Pipeline das Paket litellm==1.107.0 mit einem Credential-Stealer auf PyPI und Docker Hub; die Schadversion war rund zwei Stunden online und kam laut Wiz auf etwa 49.000 Downloads.
- Die Malware läuft bei jedem Python-Start und sammelt Browser-Passwörter, SSH- und Cloud-Schlüssel, CI-Geheimnisse und gezielt die Konfigurationen von KI-Werkzeugen wie ~/.cursor und ~/.claude.
- Angriffsweg laut LiteLLM: gestohlene GitHub-CLI-OAuth-Token dreier Entwickler-Konten, erbeutet aus den Logs einer öffentlich erreichbaren internen Installation; der GitHub-Quelltag selbst ist sauber.
- Betroffene sollen die Umgebung als kompromittiert behandeln: nicht zuerst pip starten, Schaddateien löschen, Maschinen neu aufsetzen, alle erreichbaren Schlüssel rotieren und auf 1.106.2 pinnen.
Kurz gesagt: LiteLLM, die Bibliothek, die in unzähligen KI-Anwendungen vor den Modell-API-Keys sitzt, wurde selbst zum Angriffsziel. Zwei Stunden lang lieferte die offizielle Versionsnummer 1.107.0 einen Diebstahl-Trojaner aus. Der Vorfall ist eingedämmt, aber für alle, die in dem Zeitfenster installiert oder gepullt haben, beginnt die Arbeit jetzt.
Was genau passiert ist
Am frühen Morgen des 21. Oktober wurde LiteLLMs Release-Pipeline kompromittiert und veröffentlichte die Version 1.107.0 auf PyPI und als Docker-Images, wie das LiteLLM-Team in seinem Incident-Bericht dokumentiert. Auf PyPI war das Schadpaket von 11:39 bis 13:23 UTC erreichbar, die Docker-Tags v1.107.0, latest, main-latest und main-stable von 11:46 bis etwa 14:20 UTC. Laut Wiz wurde die PyPI-Version rund 49.000-mal heruntergeladen; die Dependency-Firewall von AISLE markierte das erste Paket bereits drei Minuten und 14 Sekunden nach dem Upload. Der offizielle Quelltext-Tag auf GitHub ist sauber, die kompromittierten Pakete wurden aus einem vom Angreifer kontrollierten Repository gebaut.
Was die Malware tut
Die Schadsoftware installiert drei Dateien direkt ins site-packages-Verzeichnis: cook.pth, cook.py und sitecustomize.py. Damit startet sie bei jedem Python-Interpreter-Start, ganz ohne dass litellm importiert wird, ein zweiter Lademechanismus holt stündlich weiteren Code nach. Gesammelt werden Browser-Passwörter, SSH-Schlüssel, Cloud-Zugänge samt Instanz-Metadaten, Kubernetes-, Vault- und CI-Geheimnisse, Tokens aus .npmrc, .pypirc und .git-credentials, und bezeichnenderweise die Konfigurationen von KI-Werkzeugen, darunter ~/.cursor und ~/.claude. Die Beute wird verschlüsselt exfiltriert. Angreifer behandeln die Ordner von Coding-Agenten inzwischen also gezielt als Zugangsdaten-Lager.
Der Angriffsweg
Nach der LiteLLM-Untersuchung gelangte der Angreifer über eine öffentlich erreichbare interne Installation an GitHub-CLI-OAuth-Token, die dort in Logdateien gelandet waren. Mit den Tokens dreier Entwickler-Konten wurde der Release-Workflow ausgelöst und freigegeben. Eine Branch-Protection-Regel blockierte zunächst eine unautorisierte Workflow-Änderung, wurde aber Sekunden später von einem privilegierten Konto überstimmt. Alle beteiligten Token sind inzwischen widerrufen. Für Enterprise-Kunden verteilt LiteLLM parallel eine geschützte Version, die eine noch embargoisierte Sicherheitslücke schließt; deren Veröffentlichung ist für den 27. Oktober geplant.
Was du mitnehmen kannst
- Ein Supply-Chain-Angriff traf mit LiteLLM das Tor zu den Modell-API-Keys vieler KI-Stacks, rund 49.000 Downloads in zwei Stunden.
- Die Malware zielt ausdrücklich auf KI-Werkzeug-Konfigurationen, Agenten-Ordner sind jetzt Angriffsziel.
- Gepinnte Versionen hätten geschützt: Betroffen ist nur, wer 1.107.0 im Zeitfenster installiert oder gepullt hat.
- Gegenmaßnahmen: Schaddateien vor dem ersten Python-Start löschen, Umgebung neu aufsetzen, Schlüssel rotieren, auf 1.106.2 pinnen.
Häufige Fragen
Woher weiß ich, ob ich betroffen bin?
Suche in Lockfiles, Container-Images und CI-Caches nach litellm==1.107.0 sowie auf Dateisystemen nach litellm-1.107.0.dist-info, cook.pth und sitecustomize.py. Wer die Version zwischen 11:39 und 13:23 UTC am 21. Oktober per pip installiert oder ein betroffenes Docker-Image gestartet hat, sollte die Umgebung als kompromittiert behandeln. Ein Nichtergebnis bei der Dateisuche beweist allerdings nicht, dass alles sauber ist.
Warum darf ich nicht einfach pip install --upgrade laufen lassen?
Weil jeder Start des Python-Interpreters, also auch der von pip, die Schaddateien cook.pth und sitecustomize.py erneut ausführt. Erst die Dateien und ihre __pycache__-Reste von der Shell aus löschen, dann die Umgebung neu aufsetzen.
Ist die aktuelle Version wieder sicher?
Die Schadversion ist von PyPI, Docker Hub und GHCR entfernt, und alle am Angriff beteiligten Token wurden widerrufen. LiteLLM empfiehlt, vorerst explizit auf 1.106.2 oder eine frühere Version zu pinnen. Der GitHub-Quelltag war nie infiziert, die Pakete stammten aus einem fremden Repository.
Quellen
- Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised (LiteLLM, abgerufen 2026-10-24)
- LiteLLM Compromised, Steals Credentials (Wiz Blog, abgerufen 2026-10-24)
- AI News Oct 23, 2026: Storm-0940 weaponises ARTEX (Morning Tokens, abgerufen 2026-10-24)
Weitere Artikel
- DeepSeek legt seine Produktions-Engine DeepInfer offen
- PHP2Shell: KI findet jahrzehntealte Lücken im PHP-Kern
Transparenzhinweis: Dieser Artikel ist ein redaktioneller Beitrag von Philipp Paulik und entstand mit KI-Unterstützung (Recherche und Textentwurf). Alle Quellen sind unten verlinkt; Zahlen und Aussagen stammen aus diesen Quellen. Das Titelbild ist KI-generiert und im Bild entsprechend gekennzeichnet. Die News-Übersicht auf dieser Seite wird dagegen automatisch aus öffentlichen Feeds aggregiert. So arbeiten wir.