Zwei manipulierte Versionen der Open-Source-KI-Gateway-Software LiteLLM haben auf dem Paketindex PyPI für etwa 40 Minuten im März Code zur Entwendung von Anmeldedaten bereitgestellt. Dieser zielte darauf ab, Cloud-Schlüssel, SSH-Keys, Kubernetes-Tokens, Datenbankpasswörter und weitere Geheimnisse von Systemen zu extrahieren, die die Pakete installiert hatten. Der Vorfall ist Teil einer größeren Supply-Chain-Attacke, der sogenannten TeamPCP-Kampagne, die bereits mehrere Unternehmen kompromittiert hat.
Datenpanne: Über 2500 Organisationen potenziell betroffen
Die Bedrohungsanalysefirma CloudSEK hat nun einen Datensatz veröffentlicht, der auf rund 434.000 Dateien basiert, die die Angreifer erbeuten konnten. Die Analyse dieser Dateien kartiert eine potenzielle Exposition von mehr als 2.500 Organisationen. Es ist jedoch wichtig zu betonen, dass es sich hierbei nicht um eine definitive Liste der Opfer handelt. Die Firma stellt die Daten als öffentliches Suchtool zur Verfügung, das nach Namen oder Domain durchsucht und nach Konfidenzniveau gefiltert werden kann. Jeder Eintrag zeigt den Organisationsnamen, die Domain, die Anzahl exponierter Geheimnisse, die Anzahl der Ausführungsvorgänge und eine Bewertung von „Hoch“ oder „Mittel“. Ein hochvertrauenswürdiger Treffer bedeutet, dass die Systeme der Organisation eindeutig als Quelle der Dateien identifiziert wurden, basierend auf Identitätssignalen in der CI-Runner-Umgebung wie Host-Identität und legitimen Committer-Domains. Repositorien-Namensräume ergeben nur eine mittlere Konfidenz. Namen wie NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens und X Corp sind in der Liste enthalten. CloudSEK und LiteLLM raten den betroffenen Parteien dennoch, alle potenziell kompromittierten Zugangsdaten zu rotieren, anstatt auf einen definitiven Beweis einer tatsächlichen Nutzung zu warten.
Was ist LiteLLM und wie konnten die Malware-Releases eingeschleust werden?
LiteLLM ist ein quelloffenes KI-Gateway, das Anwendungen mit verschiedenen Modellanbietern verbindet. Die Versionen 1.82.7 und 1.82.8 wurden als kompromittiert identifiziert. Sie waren ab dem 24. März um 10:39 UTC für etwa 40 Minuten auf PyPI verfügbar, bevor sie isoliert wurden. Das Projekt rät jedoch, jede Installation an diesem Tag bis 16:00 UTC als verdächtig zu betrachten. Die Version 1.82.8 enthielt eine Datei namens litellm_init.pth, die der Python-Interpreter beim Start automatisch verarbeitet. Dies bedeutete, dass der Schadcode bei jedem Start eines Python-Prozesses in dieser Umgebung ausgeführt wurde, unabhängig davon, ob LiteLLM tatsächlich importiert wurde. Die kompromittierten Pakete sammelten Umgebungsvariablen, SSH-Schlüssel, Cloud-Anmeldedaten, Kubernetes-Tokens und Datenbankpasswörter, verschlüsselten diese Daten und sendeten sie an eine von den Angreifern kontrollierte Domain. Die Payload erfasste unter anderem die Modell-API-Schlüssel OPENAI_API_KEY und ANTHROPIC_API_KEY.
Das FBI warnte in einer Mitteilung vom 2. Juli, dass die Täter der TeamPCP-Kampagne die exfiltrierten Anmeldedaten wahrscheinlich noch lange nach dem initialen Kompromiss nutzen werden. Die Behörde empfahl, alle CI/CD-Geheimnisse, Veröffentlichungstokens und Cloud-Anmeldedaten, die während der relevanten Zeitfenster zugänglich waren, zu rotieren. Ein einmal kopiertes, langlebiges Geheimnis – etwa ein statischer Cloud-Key, ein SSH-Key oder ein Veröffentlichungstoken – bleibt nutzbar, sofern es nicht inzwischen rotiert oder widerrufen wurde.
Der Kontext: Die TeamPCP-Supply-Chain-Kampagne
Der LiteLLM-Vorfall ist Teil der breiteren TeamPCP-Supply-Chain-Kampagne, die mit dem Trivy-Scanner des Sicherheitsunternehmens Aqua Security in Verbindung steht. Google verfolgt die Gruppe unter dem Namen UNC6780. Die Angreifer erlangten über einen unvollständig rotierten Credential-Zugriff auf die Systeme von Trivy und injizierten daraufhin bösartige Commits in die Versions-Tags und veröffentlichten eine manipulierte Trivy-Version. Der Kompromiss im Ökosystem wird als CVE-2026-33634 geführt und wurde am 26. März in den Katalog bekannter ausgenutzter Schwachstellen von CISA aufgenommen. Der CVE-Eintrag listet nun BerriAI LiteLLM in den Versionen 1.82.7 bis 1.82.8 zusammen mit den Trivy-Komponenten als betroffen.
Die genaue Art und Weise, wie die bösartigen LiteLLM-Releases auf PyPI gelangten, wurde in den verschiedenen Berichten unterschiedlich dargestellt. CloudSEK berichtete von einer vergifteten Build-Pipeline, während LiteLLMs eigener Bericht auf einen direkten PyPI-Upload verwies, der den offiziellen CI/CD-Workflow umging. Unit 42 beschrieb, wie die Angreifer nach dem Trivy-Bruch auf PyPI-Veröffentlichungstokens abzielten. CloudSEK erklärte hierzu, dass es sich nicht um widersprüchliche Erklärungen handele, sondern um verschiedene Phasen derselben Angriffskette. Die Beweise von CloudSEK decken ab, wie die Zugangsdaten erlangt wurden, während die anderen Berichte zeigen, wie sie dann verwendet wurden. Die offizielle Beratung von PyPA beschreibt ebenfalls einen API-Token, der durch die kompromittierte Trivy-Abhängigkeit exponiert und dann für den Upload der beiden LiteLLM-Versionen genutzt wurde.
Wie Unternehmen ihre Exposition prüfen sollten
Organisationen, die ihre Gefährdung bewerten möchten, sollten drei konkrete Schritte befolgen: Erstens die Prüfung auf Installationen von LiteLLM in den Versionen 1.82.7 oder 1.82.8 während des Audit-Zeitraums vom 24. März, 10:39 bis 16:00 UTC. Zweitens die sofortige Rotation aller Geheimnisse, die diese Systeme einsehen konnten. Drittens die Suche in den eigenen GitHub-Organisationen nach Repositorien mit den Namen tpcp-docs oder docs-tpcp. Das FBI führt diese als Indikatoren für die Kampagne. Aqua wies jedoch darauf hin, dass die Malware diese Repositorien mit einem tpcp-docs--Präfix erstellte und die gestohlenen Daten als Release-Asset mit einem Zeitstempel hochlud. Eine exakte Namenssuche könnte diese daher übersehen.
Die Auswirkungen der Kampagne werden durch bestätigte Vorfälle bei Drittfirmen unterstrichen. Checkmarx berichtete, dass durch den Trivy-Angriff erlangte Anmeldedaten einen unbefugten Zugriff auf seine GitHub-Repositorien ermöglichten. Mercor gab an, von den bösartigen LiteLLM-Versionen betroffen gewesen zu sein, und CERT-EU bewertete mit hoher Konfidenz, dass ein AWS-Konto der Europäischen Kommission durch den Trivy-Angriff kompromittiert wurde, wobei etwa 91,7 GB an komprimierten Daten abgeflossen sein sollen.
Der Vorfall zeigt eindringlich, dass die Frage, ob ein Team wissentlich LiteLLM einsetzt, weniger relevant ist als die Frage, ob das Paket auf einem Host installiert wurde. Eine nicht fixierte transitive Abhängigkeit, die von einem Agent-Framework oder Orchestrierungstool nachgezogen wird, kann das Paket ohne das aktive Zutun des Nutzers installieren. Der Vorfall zwingt Unternehmen, ihre Abhängigkeitsketten genauer zu prüfen und von langlebigen Credentials hin zu temporären, kurzlebigen Tokens zu migrieren – eine grundlegende Änderung der Sicherheitsarchitektur, die durch solche Vorfälle weiter an Dringlichkeit gewinnt.
