LiteLLM 1.107.0 kompromittiert: Credential-Stealer über Build-Pipeline eingeschleust
Eine bösartige LiteLLM-Version auf PyPI installierte einen Credential-Stealer und eine Backdoor durch die Manipulation der Build-Konfiguration und betraf alle gängigen Betriebssysteme.
Automatisch aus dem englischen Original übersetzt.
Am 21. Oktober 2026 identifizierten Sicherheitsforscher, dass die Version 1.107.0 von LiteLLM, veröffentlicht im Python Package Index (PyPI), einen Credential-Stealer und eine Remote-Code-Execution-Backdoor enthielt. Das kompromittierte Paket wirkte sich auf Linux-, macOS- und Windows-Umgebungen aus, indem es während der Installation bösartige Dateien direkt in das Python-site-packages-Verzeichnis einschleuste. PyPI hat die Veröffentlichung inzwischen entfernt, doch der Vorfall unterstreicht erhebliche Risiken für die Integrität der Software-Lieferkette.
Was passiert ist
Der Angriff richtete sich gegen den Build-Prozess von LiteLLM, einer beliebten Bibliothek zur Integration großer Sprachmodelle. Wenn Entwickler die Version 1.107.0 mit pip installierten, wurden drei spezifische Dateien in ihrem site-packages-Ordner abgelegt: cook.pth, cook.py und sitecustomize.py. Im Gegensatz zu typischer Malware, die explizite Importanweisungen zur Ausführung erfordert, liefen diese Dateien automatisch bei jedem Start eines Python-Prozesses auf dem Host-Rechner. Das bedeutete, dass auch Anwendungen, die LiteLLM nicht direkt nutzten, den bösartigen Code auslösen konnten, wenn sie dieselbe Python-Umgebung teilten.
Das Upstream-Quellcode-Repository auf GitHub enthielt diese bösartigen Dateien nicht. Forensische Analysen ergaben, dass das Quellpaket (sdist) für Version 1.107.0 eine modifizierte pyproject.toml-Datei mit einer injizierten Zeile enthielt: data = "cook". Diese Anweisung veranlasste das Build-Tool maturin, einen versteckten Ordner cook/ in das finale Wheel-Paket zu kopieren. Das sdist selbst ließ den Ordner cook/ weg, sodass die Injektion nur in den kompilierten Binär-Wheels sichtbar war, die über PyPI verteilt wurden. Die Versionen 1.106.2, 1.107.0rc1 und 1.107.0rc2 wurden als sauber bestätigt, ebenso wie die Begleitpakete litellm-proxy-extras und litellm-enterprise.
Funktionsweise
Die bösartige Payload funktionierte über zwei primäre Mechanismen, die durch das Startverhalten von Python ausgelöst wurden. Erstens enthielt die Datei cook.pth den Befehl import cook. Python führt automatisch Importanweisungen aus, die in .pth-Dateien im Verzeichnis site-packages beim Start gefunden werden. Dies führte dazu, dass cook.py in jedem Python-Prozess ausgeführt wurde, einschließlich IDEs, CI-Pipelines und Hintergrunddiensten. Das Skript sammelte sensible Daten wie SSH-Schlüssel, Cloud-Zugangsdaten, CI/CD-Geheimnisse, Browser-Passwörter und LLM-Provider-Tokens. Anschließend verschlüsselte es diese Daten und leitete sie an eine von den Angreifern kontrollierte Domain weiter: www.litellm[.]dev.
Zweitens richtete die Datei sitecustomize.py eine persistente Backdoor ein. Dieses Skript startete einen Hintergrund-Daemon, der stündlich eine remote gespeicherte GitHub-Datei auf eine Serveradresse hin prüfte. Nach Erhalt von Anweisungen lud der Daemon zusätzlichen Code von diesem Server herunter und führte ihn aus. Die Angreifer obfuskierten den Code in cook.py unter Verwendung von Base64-Codierung und zlib-Kompression und packten etwa 61 KB Python-Code in eine einzelne Ausführungszeile, um einfache statische Analysen zu umgehen.
Forensische Hinweise deuten darauf hin, dass die Kompromittierung innerhalb der privaten Release-Pipeline des Maintainers stattfand, nicht über eine öffentliche GitHub Actions-Ausführung. Die Zeitstempel auf den kompilierten Wheels deuteten auf separate native Builds für macOS, Linux und Windows hin, was mit einer lokalen oder privaten CI-Umgebung übereinstimmt. Das Fehlen von Provenance-Attestierungen auf PyPI und die Diskrepanz zwischen dem Git-Tag und dem Quellpaket unterstützen die Theorie, dass ein Angreifer den Quellcode modifizierte, bevor er in das Build-System gelangte, möglicherweise unter Verwendung kompromittierter Zugangsdaten oder eines privaten Branches.
Wichtige Details
- Betroffene Version: Nur LiteLLM 1.107.0 auf PyPI war kompromittiert; vorherige Versionen und Release-Kandidaten sind sicher.
- Injektionsmethode: Eine modifizierte
pyproject.toml-Datei wies das Build-Tool maturin an, ein bösartigescook/-Verzeichnis in das Wheel aufzunehmen. - Persistenz: Die Malware nutzte
cook.pthundsitecustomize.py, um automatisch bei jedem Start eines Python-Prozesses auszuführen. - Datendiebstahl: Der Stealer zielte auf SSH-Schlüssel, Cloud-Zugangsdaten, AI-Tokens und Browser-Passwörter ab und sendete sie an
www.litellm[.]dev. - Quellen-Mismatch: Der Git-Tag
v1.107.0verwies auf einen Commit mit der Version 1.108.0, während das sdist einem späteren Commit entsprach, der manuelle Änderungen zur Rücksetzung der Versionsnummer und Hinzufügung der Payload enthielt. - Plattformauswirkung: Alle sieben Wheel-Varianten (Linux, macOS, Windows) enthielten die bösartigen Dateien, was eine plattformübergreifende Infektion sicherstellte.
Warum das wichtig ist
Dieser Vorfall zeigt, dass die Überprüfung des Quellcodes in öffentlichen Repositories wie GitHub nicht ausreicht, um die Sicherheit der Lieferkette zu gewährleisten. Angreifer können den Build-Prozess abfangen oder Artefakte nach dem Taggen des Quellcodes, aber vor der Veröffentlichung modifizieren. Für Engineering-Teams bedeutet dies, dass es riskant ist, einem Paket allein aufgrund seiner Repository-Historie zu vertrauen. Die Nutzung von .pth-Dateien zur Erzielung einer Codeausführung ohne explizite Imports umgeht viele Standard-Sicherheitsprüfungen, die nach gefährlichen Funktionsaufrufen im Anwendungscode suchen.
Darüber hinaus erschwerte das Fehlen von Provenance-Attestierungen auf PyPI die sofortige Verifizierung der Herkunft der kompilierten Wheels. Ohne kryptografischen Nachweis, der das gebaute Artefakt mit einem spezifischen, verifizierten Build-Prozess verknüpft, müssen Verteidiger sich auf reaktive forensische Analysen verlassen. Diese Verzögerung ermöglicht es bösartigen Paketen, länger im Umlauf zu bleiben, und erhöht das Expositions-Fenster für Organisationen, die Abhängigkeitsupdates automatisieren.
Was Sie tun können
- Deinstallieren Sie LiteLLM Version 1.107.0 sofort, falls es in einer Umgebung vorhanden ist:
pip uninstall litellm==1.107.0. - Rotieren Sie alle Zugangsdaten, API-Schlüssel und Geheimnisse, die auf Maschinen gespeichert sind, auf denen die kompromittierte Version installiert worden sein könnte.
- Prüfen Sie auf die Existenz von
cook.pth,cook.pyundsitecustomize.pyin Ihrem Python-site-packages-Verzeichnis. - Fixieren Sie Abhängigkeiten auf bekannte gute Versionen, wie z. B. 1.106.2 oder 1.107.0rc2, bis ein verifizierter Patch veröffentlicht wird.
- Aktivieren Sie Provenance-Prüfungen für Abhängigkeiten, wo verfügbar, und bevorzugen Sie Pakete, die Attestierungs-Metadaten bereitstellen.
- Überwachen Sie Netzwerkprotokolle auf ausgehende Verbindungen zu
www.litellm[.]devoder ungewöhnliche Muster der Datenexfiltration.



