Die Kompromittierung von Trivy soll den Angriff ausgelöst haben, bei dem mehr als 2.500 Organisationen exponiert wurden

LiteLLM war vermutlich nur die sichtbarste Phase

Die Supply-Chain-Kompromittierung von LiteLLM soll nicht im Projekt selbst begonnen haben. Nach einer Analyse von SOCRadar waren die meisten der mehr als 2.500 mit dem Vorfall in Verbindung gebrachten Organisationen zuvor über Trivy, ein Tool von Aqua Security, exponiert worden.

LiteLLM wäre demnach lediglich die letzte Phase einer größeren Kampagne, die der Gruppe TeamPCP zugeschrieben wird. Der Akteur wurde bereits mit Angriffen auf Open-Source-Projekte und dem Wurm Shai-Hulud in Verbindung gebracht.

Der Vorfall wurde am 14. August 2026 bekannt. Die zunächst von CloudSEK und HudsonRock verbreitete Schätzung von mehr als 2.500 Organisationen entspricht jedoch keiner vollständigen Liste bestätigter Kompromittierungen. SOCRadar konnte anhand zuordenbarer Identifikatoren 2.188 Entitäten rekonstruieren.

Der Unterschied ergibt sich aus der Verfügbarkeit von Daten, mit denen sich jeder Datensatz einer bestimmten Organisation zuordnen lässt. In der analysierten Stichprobe wurden 56 % der Datensätze als hochgradig vertrauenswürdig, 39 % als mittel und 6 % als niedrig eingestuft.

Die belastbarsten Zuordnungen basieren auf den Identitäten der CI-Hosts und den legitimen Domains der Committer. Auch in diesen Fällen beweist eine offengelegte Zugangsinformation jedoch nicht automatisch, dass sie vom Angreifer verwendet wurde.

Der Übergang von Trivy zu Software-Registries

Die Kampagne folgte einem Schema mit wurmartigen Eigenschaften. Der Schadcode wurde ausgeführt, sobald das kompromittierte Paket heruntergeladen und verwendet wurde. Anschließend suchte er nach Zugangsdaten, Tokens, API-Schlüsseln und anderen Geheimnissen in der Umgebung.

Die gesammelten Daten konnten dem Akteur den Zugriff auf weitere Repositories oder Registries ermöglichen. Entwicklerzugänge wurden anschließend wiederverwendet, um für den Angreifer erreichbare Pakete zu verändern und manipulierte Versionen zu veröffentlichen.

Der erste beobachtete Punkt in der Angriffskette war ein schädlicher Trivy-Build. Die erste Datensammlung wurde am 19. März um 18:05 UTC registriert – nur 18 Minuten nach der Veröffentlichung des kompromittierten Builds.

Die Aktivität nahm am 22. und 23. März zu, als manipulierte Trivy-Images auf Docker Hub verfügbar waren. In dieser Phase soll die Malware zahlreiche Entwicklungs- und Continuous-Integration-Umgebungen erreicht und Informationen aus den Systemen gesammelt haben, die zum Erstellen und Bereitstellen von Software eingesetzt wurden.

Am 24. März wurden zwei schädliche LiteLLM-Versionen veröffentlicht. Die genauen Versionsnummern wurden nicht bekannt gegeben. Die Pakete waren etwa 40 Minuten lang auf PyPI verfügbar, bevor sie unter Quarantäne gestellt wurden.

Dieser Zeitraum beschreibt nicht die gesamte Dauer der Exposition. SOCRadar zufolge handelte es sich lediglich um die letzte Phase einer Kampagne, die mit der Kompromittierung von Trivy begonnen hatte. Die letzte festgestellte Aktivität datiert auf den 24. März um 20:09 UTC.

Bei 2.085 Organisationen – 95 % der analysierten Entitäten – war die Datensammlung bereits abgeschlossen, bevor die LiteLLM-Pakete veröffentlicht wurden. Dies stützt die Annahme, dass LiteLLM als letzter oder sichtbarster Schritt und nicht als Ursprung der Operation genutzt wurde.

Warum die .pth-Payload einige Schutzmaßnahmen umgehen konnte

Die manipulierten LiteLLM-Pakete enthielten eine Datei mit der Endung .pth. Python kann solche Dateien beim Start des Interpreters automatisch laden und ausführen, selbst wenn die Anwendung LiteLLM nicht direkt importiert.

Dieses Verhalten vergrößert die Angriffsfläche erheblich. Eine Organisation konnte die kompromittierte Umgebung installieren oder starten, ohne die schädliche Komponente ausdrücklich im eigenen Code aufzurufen.

Der Mechanismus ermöglichte außerdem die Umgehung von Schutzmaßnahmen auf Basis der Option ignore-scripts. Diese Einstellung kann die Ausführung von Skripten während der Paketinstallation verhindern, blockiert jedoch nicht zwingend das automatische Laden einer .pth-Datei durch den Python-Interpreter.

Die Persistenz auf bereits infizierten Systemen stellt ein zusätzliches Risiko dar. Selbst nach der Entfernung des ursprünglichen Pakets konnte die Payload in der kompromittierten Umgebung weiter aktiv bleiben.

Die Quarantäne der Pakete auf PyPI hat die beobachtete Aktivität daher zwar unterbrochen, schließt aber weder bereits ausgeführte Komponenten noch bereits gestohlene Zugangsdaten aus.

CI/CD, Cloud und Entwickleridentitäten im Visier

Die Kampagne betraf sechs Plattformen für Continuous Integration und Continuous Delivery:

• GitHub Actions;
• GitLab CI;
• Jenkins;
• Bitbucket;
• CircleCI;
• Buildkite.

Die Einbindung dieser Umgebungen ist besonders kritisch. CI/CD-Pipelines verfügen häufig über Berechtigungen zum Lesen von Quellcode, Erstellen von Artefakten, Veröffentlichen von Paketen und Zugreifen auf Cloud-Infrastrukturen.

Die betroffenen Organisationen waren weltweit verteilt. Deutschland, Brasilien und Frankreich waren in der Rekonstruktion am stärksten vertreten.

Mehr als 1.000 Organisationen sollen JWT- und Authentifizierungstokens offengelegt haben. Zu den weiteren identifizierten Daten zählen private Schlüssel, AWS-Schlüssel, GitLab-Tokens, OpenAI-API-Schlüssel, Slack-Webhooks, GitHub-Actions-Tokens und Google-API-Schlüssel.

Bei mehr als 1.100 Organisationen sollen außerdem die E-Mail-Adressen der Committer gesammelt worden sein. Die Verknüpfung von Entwickleridentitäten mit Tokens, die von automatisierten Prozessen verwendet werden können, erleichtert gezielte Angriffe, Identitätsmissbrauch und weiteren Zugriff auf Entwicklungssysteme.

Einige Datensätze weisen eine außergewöhnlich hohe Zahl an Geheimnissen auf: Der umfangreichste soll rund 3.477 enthalten, ein weiterer etwa 3.459, verteilt auf nur sechs Dateien. Die mit diesen Fällen verbundenen Organisationen wurden nicht identifiziert.

Die Daten sollen bereits auf dem kriminellen Markt verfügbar sein

Die gestohlenen Geheimnisse sollen nicht ausschließlich in den Systemen des Angreifers verblieben sein. Eine Person bewirbt auf Telegram eine Sammlung, die Daten aus LiteLLM, Trivy und CanisterWorm enthalten soll.

Unklar ist, ob das gesamte Material aus derselben Phase der Kampagne stammt. Die Sammlung könnte zu unterschiedlichen Zeitpunkten zusammengestellt worden sein. Ihre Verfügbarkeit erhöht jedoch in jedem Fall das operative Risiko für exponierte Organisationen.

CI/CD-Tokens, Cloud-Schlüssel und Entwicklerzugänge können verwendet werden, um auf Repositories zuzugreifen, Pipelines zu verändern, neue schädliche Pakete zu veröffentlichen oder externe Dienste zu erreichen. API-Schlüssel können außerdem Kosten verursachen, den Zugriff auf Daten ermöglichen oder für automatisierte Aktivitäten missbraucht werden.

Die Kombination aus automatischer Verbreitung und der Wiederverwendung von Zugangsdaten erklärt, warum der Vorfall nicht auf LiteLLM beschränkt betrachtet werden sollte. Ein einziges kompromittiertes Paket kann zum Einstiegspunkt in ein Netzwerk aus Projekten, Pipelines und Software-Registries werden.

Was exponierte Organisationen prüfen sollten

Die einzige dokumentierte Eindämmungsmaßnahme ist die Quarantäne der schädlichen LiteLLM-Pakete durch PyPI. Spezifische Patches, korrigierte Versionen, offizielle Bereinigungsverfahren oder eine vollständige Liste technischer Indikatoren wurden nicht veröffentlicht.

Organisationen, die Trivy oder LiteLLM in den betroffenen Umgebungen eingesetzt haben, sollten ihre CI/CD-Pipelines und Repositories sowie das Vorhandensein unerwarteter .pth-Dateien prüfen. Die identifizierten Geheimnisse sollten bis zu einer unabhängigen Validierung als potenziell kompromittiert betrachtet werden.

Die bloße Entfernung des Pakets reicht nicht aus, um eine Persistenz auszuschließen. Auch Hosts, auf denen der Code ausgeführt worden sein könnte, müssen überprüft werden. Zudem sollten Veröffentlichungen, Repository-Änderungen und ungewöhnliche spätere Zugriffe analysiert werden.

Das Briefing enthält keine offiziellen Anweisungen der Anbieter zur Behebung und bestätigt auch nicht, ob die Schwachstelle oder die Kampagne in den KEV-Katalog der CISA aufgenommen wurde. Angaben zu einem Aufnahmedatum oder einer einzuhaltenden CISA-Frist liegen daher nicht vor.

Operativ hat weiterhin die Widerrufung und Ersetzung potenziell offengelegter Zugangsdaten Priorität, ebenso wie die Überprüfung der Pipeline-Berechtigungen. Solange nicht vollständig geklärt ist, ob die Geheimnisse verwendet wurden, sollten sie vorsichtshalber als kompromittiert behandelt werden.