Im vergangenen Monat rückte erneut eine Lieferketten-Story ins Zentrum: maliziöses LiteLLM, das offenbar mit einem kompromittierten Trivy-Umfeld zusammenhing. Zwei infizierte LiteLLM-Versionen gelangten rund 40 Minuten lang auf PyPI – mit Code, der gezielt Zugangsdaten einsammeln konnte.
Laut aktuellen Auswertungen soll dabei eine große Zahl von Organisationen potenziell betroffen gewesen sein. Wichtig: Die Kennzahlen bedeuten nicht, dass bei allen benannten Firmen nachweislich Credentials missbraucht wurden. Vielmehr geht es um festgehaltene Beute- und Logdaten aus dem Angriffskontext.
Was an maliziösem LiteLLM bekannt ist
Die betroffenen Pakete lagen im März etwa 40 Minuten auf PyPI. In dieser Zeit wurden Versionen ausgeliefert, die laut Threat-Intelligence-Analysen Credential-Stealing betrieben. Die Schadlogik war darauf ausgelegt, verschiedene Arten von Geheimnissen aus dem System zu sammeln, auf dem das Paket installiert wurde.
Dazu zählten unter anderem Cloud-Schlüssel, SSH-Schlüssel, Kubernetes-Token sowie Datenbankpasswörter und weitere Secrets, die als Umgebungsvariablen vorliegen können. Danach sollten die erbeuteten Informationen verschlüsselt und zu einer vom Angreifer kontrollierten Infrastruktur gesendet werden.
Besonders kritisch ist dabei der Installationskontext: Eine der kompromittierten Versionen enthielt eine Datei, die beim Start von Python-Prozessen automatisch ausgeführt werden konnte. Dadurch konnte der Code im kompromittierten Umfeld laufen, selbst wenn LiteLLM nicht bewusst importiert wurde.
Welche LiteLLM-Versionen betroffen waren
Das Projekt selbst identifizierte die Versionen 1.82.7 und 1.82.8 als kompromittiert. Laut Projektangaben waren diese Pakete am 24. März ab 10:39 UTC für ungefähr 40 Minuten online, bevor PyPI sie quarantänisiert hat.
LiteLLM empfahl zudem, bis 16:00 UTC am selben Tag jede Installation als verdächtig zu behandeln. Währenddessen blieb die Veröffentlichungsgeschichte laut einer Kontrolle auf PyPI am 12. August widersprüchlich: Die fraglichen Versionen tauchten dort offenbar nicht regulär im Release-Historienverlauf auf, während angrenzende Versionen verfügbar blieben.
Warum die Zahl „2.100+“ nicht gleichbedeutend mit „Opfer“ ist
Ein Intelligence-Dienstleister veröffentlichte eine öffentlich durchsuchbare Datensammlung, die auf einer großen Zahl erbeuteter Dateien basiert. Die Grundlage bildeten etwa 434.000 Dateien, die im Zuge des Angriffs erfasst wurden.
Die Datensätze ordnen potenzielle Exposition einzelnen Organisationen zu. Dabei erscheinen Einträge häufig mit einer Einstufung wie High oder Medium, abhängig von den Signalen, die im CI-Runner-Umfeld festgestellt wurden.
Doch: Diese Zahlen sind laut den Verantwortlichen kein „Victim Count“. Die Datensätze seien aus vertraulichen Quellen entstanden und bestünden aus Loot- und Log-Dateien, die dem Kampagnenkontext zugeordnet wurden. Die Auswertung zeigt also, welche Identitätssignale in der kompromittierten Umgebung gefunden wurden – nicht zwingend, ob die Secrets bei jeder genannten Organisation tatsächlich genutzt wurden.
Wie Zuordnung in der Datensammlung funktioniert
Die Verknüpfung zwischen Datei und Organisation basiert auf zwei unabhängigen Prüfschritten. Ein Index nutzt dabei CI-Identitätsvariablen, während ein zweiter Mechanismus die Zuordnung anhand der abgeholten Logs neu ableitet und bei Bedarf übersteuern kann.
Wenn die Ergebnisse nicht übereinstimmen, wird der Bericht zurückgehalten. In der endgültigen Bewertung wird dabei das jeweils niedrigere Konfidenzniveau berücksichtigt. Zusätzlich gilt: Namespace-Ergebnisse liefern eher eine Medium-Einschätzung, während ein High-Match insbesondere dann vergeben wird, wenn Identitätssignale zusammenpassen und die eigene Domain der Organisation vorliegt.
LiteLLM hängt in eine größere Trivy-/TeamPCP-Kette
Die Ereignisse rund um maliziöses LiteLLM sind nicht isoliert zu betrachten. Die Analysen ordnen die Aktivitäten dem breiteren TeamPCP-Supply-Chain-Kontext zu, der mit dem Trivy-Scanner in Verbindung steht.
In diesem Zusammenhang wird außerdem ein Tracking als UNC6780 erwähnt. Zudem gab es Berichte, dass Angreifer nach einer unvollständigen Rotation von Zugangsdaten weiterhin Zugriff behielten. Teilweise sollen dabei Änderungen an Trivy-bezogenen Versionstagen über mehrere Varianten erzwungen worden sein sowie eine bösartige Trivy-Veröffentlichung inkludiert gewesen sein.
Die betroffene Ökosystem-Kette ist als CVE-2026-33634 dokumentiert. Zudem tauchte der Eintrag später im CISA Known Exploited Vulnerabilities-Katalog auf.
Uneinigkeit zur Kompromittierung: PyPI-Upload oder Token-Abgriff?
Wie die infizierten LiteLLM-Pakete letztlich in PyPI gelangten, wird in den veröffentlichten Darstellungen unterschiedlich beschrieben.
Ein Bericht beschreibt, dass der Build von den Angreifern erzeugt und veröffentlicht wurde. Die LiteLLM-eigene Incident-Dokumentation verweist dagegen auf einen direkten PyPI-Upload, der den üblichen CI/CD-Prozess umging. Unit 42 wiederum nennt einen Ansatz, bei dem Angreifer insbesondere Publishing-Tokens nach der Trivy-bezogenen Kompromittierung angegriffen haben sollen.
Die divergierenden Aussagen werden von einem der Beteiligten als unterschiedliche Phasen einer gemeinsamen Angriffsserie eingeordnet: Während die einen Angaben mehr auf das „Wie erhielt man den Zugriff?“ abzielen, fokussieren andere Quellen auf das „Wie wurde die Veröffentlichung konkret genutzt?“
Warum Rotieren jetzt wichtiger ist als Abwarten
Ein zentraler Punkt der Empfehlungen lautet: Selbst wenn nicht klar ist, ob eine konkrete Organisation tatsächlich sofort Opfer von Credential-Missbrauch wurde, sollten betroffene Teams nicht abwarten.
Hintergrund: Langfristige Secrets können auch nach dem initialen Ereignis weiterhin nutzbar bleiben. Wenn ein Token, Cloud-Key oder SSH-Schlüssel nicht rotiert oder widerrufen wird, besteht ein Risiko für späteren Zugriff – unabhängig davon, ob der ursprüngliche Angriff nur kurz online war.
Behördliche Hinweise legen daher den Fokus auf das Rotieren von CI/CD-Zugangsdaten, das Ersetzen von veröffentlichten Tokens sowie den Wechsel zu temporären Credentials anstelle langlebiger Schlüssel.
Konkrete Schritte für die Risiko-Einschätzung
Für Organisationen, die ihre Lage prüfen möchten, werden drei praktische Schritte genannt:
- LiteLLM-Installationen prüfen: Kontrollieren Sie, ob auf Ihren Systemen LiteLLM 1.82.7 oder 1.82.8 installiert wurden – insbesondere im Zeitfenster der Veröffentlichung/Quarantäne am 24. März zwischen 10:39 UTC und 16:00 UTC.
- Secrets rotieren: Wenn Systeme in diesem Zeitraum betroffen gewesen sein könnten, rotieren bzw. widerrufen Sie alle Zugangsdaten, auf die diese Umgebung Zugriff hatte.
- GitHub-Indikatoren suchen: Ergänzend wird empfohlen, in GitHub-Organisationen nach Repositories zu suchen, deren Namen als Indikatoren gelten, u. a. „tpcp-docs“ oder „docs-tpcp“. Da die Artefakte in einem bestimmten Muster hochgeladen wurden, kann eine exakte Trefferquote sonst übersehen werden.
Bestätigter Folgeschaden in der Praxis
Selbst wenn die skalierte Expositionszahl nicht automatisch gleich Opfer bedeutet, sind die Auswirkungen in der Breite nicht rein theoretisch. In veröffentlichten Analysen wird beschrieben, dass Credentials aus der Trivy-Kompromittierung zu unerlaubtem Zugriff geführt und zudem die Veröffentlichung bösartiger Artefakte ermöglicht haben sollen.
Auch einzelne Organisationen meldeten, dass sie durch die kompromittierten LiteLLM-Versionen betroffen gewesen sein könnten und dabei unerwünschte Aktivitäten im Umfeld beobachteten.
Fazit
Maliziöses LiteLLM wurde offenbar über zwei kurzzeitig kompromittierte PyPI-Pakete verbreitet, die im März für rund 40 Minuten online waren. Der Diebstahlcode zielte darauf, unter anderem Cloud-Schlüssel, SSH-Zugänge, Kubernetes-Token und Datenbankpasswörter aus dem betroffenen Umfeld zu erheben und an eine Angreiferinfrastruktur zu übermitteln.
Die veröffentlichten Expositionsdaten deuten auf eine große Zahl potenziell betroffener Organisationen hin, sagen aber nicht automatisch, dass jede genannte Firma tatsächlich Credentials verloren hat oder missbräuchlich genutzt wurden. Gerade deshalb ist das empfohlene Vorgehen klar: prüfen, Rotationen umsetzen und nach konkreten Kampagnenindikatoren suchen.
Quelle: https://thehackernews.com/2026/08/malicious-litellm-releases-tied-to.html
