LiteLLM Supply-Chain-Angriff vom 24. März 2026 kompromittierte zwei PyPI-Versionen mit einem dreistufigen Credential-Stealer. Was passiert ist, wer betroffen ist und was Unternehmen jetzt tun müssen.
Ein LiteLLM Supply-Chain-Angriff Report steht mit allen verifizierten IOCs, Prüfbefehlen und einem vierphasigen Incident-Response-Playbook zum Download bereit.
LiteLLM Supply-Chain-Angriff entstand über die Trivy-Kompromittierung
Der LiteLLM Supply-Chain-Angriff vom 24. März 2026 kompromittierte zwei PyPI-Versionen der beliebten Python-Bibliothek mit einem dreistufigen Credential-Stealer. Der Schadcode sammelte unter anderem SSH-Schlüssel, Cloud-Zugangsdaten, Kubernetes-Secrets und LLM-API-Keys, verschlüsselte sie und übermittelte sie an eine vom Angreifer kontrollierte Domain. Hinter dem Angriff steht nach übereinstimmender Einschätzung mehrerer Sicherheitsunternehmen dieselbe Gruppe, die wenige Tage zuvor bereits den Trivy-Scanner kompromittiert hatte.
LiteLLM ist eine Python-Bibliothek, die als einheitliche Schnittstelle zu über 100 KI-Modellanbietern dient. Sie wird täglich rund 3,4 Millionen Mal von PyPI heruntergeladen, wobei der Großteil auf automatisierte CI/CD-Läufe entfällt. Kursierende Opferzahlen in sechsstelliger Höhe sind bislang nicht belegt und sollten mit Vorsicht betrachtet werden.
Der Angriffsweg führte über die wenige Tage zuvor kompromittierte Trivy-CI/CD-Integration, die in diesem Beitrag ausführlich beschrieben wurde. LiteLLMs Build-Pipeline nutzte Trivy als Sicherheitsscanner und installierte es ohne Versions-Pinning. Die kompromittierte Trivy-Version exfiltrierte dabei ein PyPI-Publish-Token aus der GitHub-Actions-Umgebung. Mit diesem Token lud der Bedrohungsakteur TeamPCP zwei schadhafte Versionen direkt auf PyPI hoch, ohne den regulären GitHub-Release-Prozess zu durchlaufen. Zwei-Faktor-Authentifizierung war auf den Maintainer-Accounts aktiv, wurde aber durch das gestohlene API-Token umgangen. LiteLLMs CEO bestätigte diesen Ablauf öffentlich.
Wie der Schadcode in den kompromittierten Versionen funktioniert
Die am 24. März um 10:39 UTC veröffentlichte Version 1.82.7 enthielt zwölf Zeilen obfuszierten Base64-Code in der Datei proxy_server.py, der beim Import des LiteLLM-Proxy-Moduls ausgeführt wurde. Dreizehn Minuten später folgte Version 1.82.8 mit einem zusätzlichen, deutlich aggressiveren Vektor: einer .pth-Datei im Wheel-Root, die Python bei jedem Interpreter-Start automatisch verarbeitet. Damit genügte nicht der Import der Bibliothek, sondern jeder beliebige Python-Prozess in der betroffenen Umgebung löste den Schadcode aus – einschließlich pip, pytest oder dem Language-Server einer IDE. Ein Bug in dieser Implementierung erzeugte eine unkontrollierte Prozessvervielfachung, die zur RAM-Erschöpfung führte und dadurch die Entdeckung durch einen Entwickler bei FutureSearch auslöste.
Der Payload operierte in drei Stufen: Zunächst sammelte er systematisch Zugangsdaten vom Host, darunter SSH-Schlüssel, AWS-, GCP- und Azure-Credentials, Kubernetes-Konfigurationen, Datenbankpasswörter, Git-Credentials, Shell-Historien und Kryptowährungs-Wallets. Anschließend verschlüsselte er die gesammelten Daten mit AES-256-CBC und RSA-4096 und übermittelte sie an die C2-Domain models.litellm[.]cloud, die am Vortag registriert worden war. In einer dritten Stufe installierte der Schadcode eine persistente Backdoor unter ~/.config/sysmon/sysmon.py mit zugehörigem systemd-Service und versuchte in Kubernetes-Umgebungen, privilegierte Pods auf jedem Node zu deployen.
Wer vom LiteLLM Supply-Chain-Angriff betroffen sein kann
PyPI stellte das Paket gegen 13:38 UTC unter Quarantäne, die endgültige Löschung der kompromittierten Versionen erfolgte am Nachmittag. Das konservative Betroffenheitsfenster reicht damit von 10:39 bis etwa 15 Uhr UTC. Nicht betroffen waren laut offiziellem Statement Nutzer des LiteLLM-Docker-Images, der Cloud-Variante oder Installationen direkt aus dem GitHub-Repository. Potenziell betroffen ist dagegen jede Umgebung, die in diesem Zeitfenster eine ungepinnte pip-Installation von LiteLLM durchgeführt hat. Das schließt ausdrücklich transitive Installationen ein: Der Erstentdecker bei FutureSearch hatte LiteLLM nie bewusst installiert – es wurde durch ein Cursor-MCP-Plugin als Abhängigkeit mitgebracht.
Alle bisher dokumentierten IOCs und Persistenz-Mechanismen beziehen sich auf Linux-Systeme. Ob und wie der Schadcode auf Windows oder macOS wirkt, ist zum Zeitpunkt dieser Veröffentlichung nicht dokumentiert, wobei der .pth-Mechanismus selbst plattformübergreifend funktioniert.
Was Unternehmen jetzt tun sollten
Wer prüfen will, ob eigene Systeme betroffen sind, sollte auf allen Maschinen, CI/CD-Runnern und in Docker-Images pip show litellm ausführen und nach der Datei litellm_init.pth in den site-packages-Verzeichnissen suchen. Bei einem Fund der Versionen 1.82.7 oder 1.82.8 müssen sämtliche auf dem betroffenen System zugänglichen Credentials als kompromittiert behandelt und rotiert werden. Das betrifft SSH-Schlüssel, Cloud-Provider-Zugangsdaten, Kubernetes-Secrets, LLM-API-Keys, Datenbankpasswörter und CI/CD-Tokens gleichermaßen.
Dieser Vorfall ist Teil einer laufenden Kampagne, die nach übereinstimmender Einschätzung von Endor Labs, Snyk und Wiz bislang fünf Ökosysteme durchlaufen hat. Die operative Konsequenz geht deshalb über den Einzelfall hinaus: Dependencies pinnen, Publish-Tokens durch Trusted Publishing ersetzen, Egress-Monitoring für Entwicklerumgebungen einführen und CI/CD-Runner nicht länger als vertrauenswürdige Infrastruktur behandeln, sondern als das, was sie sind – potenziell exponierte Systeme.
