Lieferkettenangriff über Trivy und LiteLLM: CI/CD-Pipeline vor CVE-2026-33634 schützen

Bei der automatisierten Softwareentwicklung verlassen sich Millionen von Pipelines auf Sicherheitstools wie Trivy und Checkmarx AST, die in den Erstellungsprozess integriert sind. Genau diese vertrauenswürdigen Lösungen wurden jüngst zum Ausgangspunkt für einen der größten und gefährlichsten Lieferkettenangriffe des digitalen Zeitalters. Unsere Fragen in diesem Artikel: Wie werden automatisierte Workflows überprüft? Und wie lässt sich die Cloud-Infrastruktur eines Unternehmens schützen?

Chronologie des Angriffs und bekannte Folgen

Am 19. März wurde über Trivy erfolgreich ein gezielter Lieferkettenangriff ausgeführt. Trivy ist ein Open-Source-Tool zur Schwachstellensuche, das für CI/CD-Pipelines sehr beliebt ist. Den Angreifern (einer als „TeamPCP“ bekannten Hackergruppe) gelang es, Malware in offizielle GitHub Actions-Workflows und Docker-Images, die mit Trivy verbunden sind, zu injizieren. Die Folge: Bei jeder automatisierten Pipeline-Untersuchung wurde Malware gestartet, die SSH-Schlüssel, Token für den Cloud-Zugriff, Krypto-Wallets und andere wertvolle Daten aus den kompromittierten Systemen stahl. Da der Vorfall kritisch war, erhielt er die Kennung CVE-2026-33634 und erreichte fast den maximalen CVSS4B-Score von 9,4.

Das Trivy-Team erkannte den Angriff noch am selben Tag und entfernte bösartige Artefakte aus den Distributionskanälen. Damit war diese Angriffsphase gestoppt. In der Zwischenzeit hatten die Angreifer sich jedoch schon Zugriff auf die Umgebungen vieler Trivy-Nutzer verschafft.

Am 23. März wurde ein ähnlicher Vorfall in einem anderen Tool für Anwendungssicherheit entdeckt: in einer GitHub Action für Checkmarx KICS sowie Checkmarx AST. Drei Stunden später wurde der Schadcode auch von dort entfernt. TeamPCP landete jedoch einen weiteren Treffer und kompromittierte die von Checkmarx unterstützten OpenVSX-Erweiterungen cx-dev-assist 1.7.0 und ast-results. Es gibt unterschiedliche Angaben darüber, wann dieser Teil des Vorfalls behoben wurde.

Am 24. März wurde LiteLLM AI Gateway angegriffen, ein populäres Projekt, das die Code-Untersuchung von Trivy verwendet und als universelle Bibliothek für den Zugriff auf verschiedene LLM-Anbieter dient. Die kompromittierten Versionen 1.82.7 und 1.82.8 wurden die in das PyPI-Repository hochgeladen. Und sie waren etwa fünf Stunden lang öffentlich verfügbar.

Obwohl der Angriff nur wenige Stunden dauerte, darf der Vorfall nicht unterschätzt werden. Angesichts der Beliebtheit der betroffenen Projekte könnte der bösartige Code tausende Male ausgeführt worden sein, darunter auch in der Infrastruktur sehr großer Unternehmen.

Die Angreifer konnten persistente Backdoors in Kubernetes-Clustern einbauen und den sich selbst replizierenden CanisterWorm im JavaScript-npm-Ökosystem starten.

Der Code der Angreifer verfügt über destruktive Fähigkeiten, die einen Kubernetes-Cluster und alle seine Knoten löschen, wenn er Teheran als Zeitzone oder Farsi als primäre Sprache auf dem kompromittierten System erkennt. In anderen Regionen begnügt sich die Malware mit dem Diebstahl von Daten. Dies erledigt CanisterWorm.

Experten zufolge gelten mehr als 20.000 Repositorys als potenziell anfällig. Die Angreifer behaupten, Hunderte Gigabyte an Daten und mehr als eine halbe Million Accounts gestohlen zu haben.

Wie Trivy angegriffen wurde

Zur Kompromittierung von Trivy verwendeten die Angreifer Anmeldeinformationen, die sie schon früher gestohlen hatten. Der vorhergehende Trivy-Vorfall fand Ende Februar statt und konnte offenbar nicht vollständig eingedämmt werden. Als setzten die TeamPCP-Hacker zu einer neuen Attacke an. Nach dem Vorfall wurden die Anmeldedaten zwar schrittweise ersetzt. Aqua Security, das Trivy entwickelt, vermutet jedoch, dass die Angreifer neue Zugriffstoken generierten, bevor alle kompromittierten Token gesperrt wurden.

Darum gelang es TeamPCP, GitHub Actions zu kompromittieren, die in CI/CD-Pipelines eingesetzt wurden. Die Angreifer verfügten über Anmeldedaten mit Schreibrechten für Tags. Sie überschrieben 76 von 77 Versions-Tags in aquasecurity/trivy-action sowie alle sieben Tags in aquasecurity/setup-trivy und leiteten vorhandene vertrauenswürdige Versionen in bösartige Commits um. Eine ähnliche Taktik wurde in der Kampagne von Shai-Hulud 2.0 beobachtet. Daraufhin wurden in den Workflows der gesamten Pipeline bösartiger Code ausgeführt, während in den Release-Metadaten keine verdächtigen Änderungen bemerkbar waren.

Gleichzeitig veröffentlichten die Angreifer eine infizierte Trivy-Binärdatei (v0.69.4) in offiziellen Distributionskanälen, darunter bei GitHub Releases und in Container-Registern.

Kompromittierung von LiteLLM

Eine Kompromittierung von LiteLLM, eines beliebten Zugriffstools für Sprachmodelle, konnte eine umfangreiche Angriffswelle auf die gesamte Kette der betroffenen Projekte auslösen. Der Angriff ereignete sich am 24. März 2026: TeamPCP veröffentlichte schädliche Versionen der Bibliothek (1.82.7 und 1.82.8) direkt auf PyPI. Zwischen 10:39 UTC und 16:00 UTC enthielten diese kompromittierten Pakete Malware, die Anmeldedaten stahl. Sie war in die Datei proxy_server.py eingebettet, und Version 1.82.8 enthielt zudem die bösartige Datei litellm_init. Die gestohlenen Daten wurden auf den Server models.litellm[.]cloud abgeschöpft.

Kunden, die LiteLLM Cloud oder das offizielle Docker-Image von LiteLLM Proxy verwendeten, waren dank einer strengen Versionssperre nicht betroffen. Entwickler und nachgelagerte Projekte, die im genannten Zeitfenster nicht angeheftete Versionen über pip installierten, wurden dagegen kompromittiert.

Innerhalb von drei Stunden wurden die bösartigen Pakete aus dem PyPI-Repository entfernt. Das LiteLLM-Team sperrte neue Versionen, rotierte die Anmeldeinformationen und leitete einen externen Prozess zur Vorfallreaktion ein. Teams, die LiteLLM in ihren Projekten verwenden, wird empfohlen, sofort nach dem Kompromittierungsindikator litellm_init.pth zu suchen und alle potenziell kompromittierten Geheimnisse routinemäßig zu rotieren.

Funktionen der Stealer-Malware TeamPCP Cloud

Die Angreifer fügten GitHub Actions und der ausführbaren Trivy-Datei eine neue Logik hinzu, während die ursprüngliche Funktionalität beibehalten wurde. Die Ergebnisse des Trivy-Schwachstellen-Scans schienen normal zu sein. Gleichzeitig wurden jedoch wertvolle Daten gesucht und extrahiert. Der bösartige Code stellte Folgendes an:

• Spionage (Sammeln von Netzwerkdaten und Umgebungsvariablen)
• Suche nach Token und Anmeldeinformationen für den Zugriff auf AWS- und GCP-Cloud-Umgebungen
• Untersuchung des Speichers (/proc/*/mem), um Geheimnisse zu extrahieren, die sich im Speicher der Prozesse Runner.Worker und Runner.Listener befinden
• Extraktion von Kubernetes-Geheimnissen (/run/secrets/kubernetes.io/serviceaccount)
• Erfassung von Daten für die Verbindung mit Datenbankservern (MySQL, PostgreSQL, MongoDB, Redis, Vault)
• Sammeln anderer API-Schlüssel und Geheimnisse aus Umgebungsdateien und CI/CD-Konfigurationsdateien (.env, .json, .yml)
• Suche nach Webhooks für Slack- und Discord-Kanäle
• Suche nach Daten, die sich auf Krypto-Wallets beziehen (Variablen, die mit der Solana-Blockchain verknüpft sind, sowie rpcuser– und rpcpassword-Daten)

Die gesammelten Daten wurden verschlüsselt und auf einen Server mit einem ähnlichen Namen wie dem der Trivy-Entwickler hochgeladen (scan.aquasecurtiy[.]org). Als Backup-Mechanismus stellten die Angreifer die Methode docs-tpcp für den Daten-Upload in ein Repository bereit.

Der Angriff auf CheckMarx und LiteLLM nutzte eine ähnliche Taktik mit anderen Typosquatting-Domänen: models.litellm[.]cloud und checkmarx[.]zone.

Eine detaillierte technische Analyse der Malware sowie die Kompromittierungsindikatoren findest du in unserem Expertenartikel im Securelist-Blog.

Reaktionen und Abwehrstrategien für CVE-2026-33634

Die bestehenden signaturbasierten Prüfungen und die Abhängigkeitsuntersuchung in öffentlichen Registern reichen nicht mehr aus, da der bösartige Code direkt in vertrauenswürdige, signierte Aktionen eingeschleust wurde und erst durch Verhaltensüberwachung enttarnt werden konnte. CI/CD-Pipelines sind zum „neuen Perimeter“ der Sicherheit geworden.

Dringende Maßnahmen. Überprüfe, ob alle Workflows sichere Versionen verwenden (Trivy-Binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

Administratoren von CI/CD-Pipelines und Sicherheitsteams sollten die Abhängigkeiten der Lösungen von Checkmarx (kics-github-action, ast-github-action) und Trivy (setup-trivy und trivy-action) sofort überprüfen. Wenn Workflows auf ein Versions-Tag verwiesen haben (anstatt auf einen bestimmten SHA-Hash), müssen die Workflow-Ausführungsprotokolle für den Zeitraum des aktiven Lieferkettenangriffs sorgfältig überprüft werden.

Zudem solltest du einen genauen Blick in die Netzwerkprotokolle werfen. Gab es Datenverkehr zu den Domänen scan.aquasecurtiy[.]org, checkmarx[.]zone und models.litellm[.]cloud? Wenn ja, so wurden sensible Daten erfolgreich exfiltriert.

Wenn auf dem Unternehmens-GitHub ein Repository namens docs-tpcp aufgetaucht ist, kann dies ebenfalls auf einen erfolgreichen Datendiebstahl hinweisen.

Überprüfe Hosts und Cluster auf Kompromittierungsspuren: Gibt es Dateien wie ~/.config/sysmon/sysmon.py oder verdächtige Pods in Kubernetes?

Leere den Cache und führe eine Inventarisierung der PyPI-Module durch: Suche nach bösartigen Modulen und setze auf saubere Versionen zurück.

Auf jeden Fall sollte ein proaktives Threat Hunting erfolgen, da man davon ausgehen muss, dass die Systeme kompromittiert wurden und sich die Einbrecher innerhalb der betroffenen Systeme ausbreiten konnten.

Zusätzlicher Tipp: die betroffenen Umgebungen aus verifizierten Backups wiederherstellen!

Abhängigkeiten anheften und Geheimnisse verwalten. Stelle sicher, dass präzise Abhängigkeitsversionen mithilfe von kryptografischen Hashes in allen Pipelines und Dockerfiles angeheftet sind. Es wird empfohlen, mithilfe eines Secrets-Manager-Tools von langlebigen Token zu kurzlebigen Anmeldeinformationen zu wechseln und OIDC-Integrationen zu implementieren (sofern diese unterstützt werden). Minimiere die Injektion von Geheimnissen in die Laufzeitumgebung. Diese sollte nur erfolgen, wenn es unbedingt erforderlich ist. Stelle sicher, dass Geheimnisse nicht auf der Festplatte oder in temporären Dateien gespeichert und nicht in verschiedenen Prozessen wiederverwendet werden.

Rotiere alle potenziell kompromittierten Anmeldeinformationen: API-Schlüssel, Umgebungsvariablen, SSH-Schlüssel, Token für Kubernetes-Dienstkonten sowie andere Geheimnisse.

Weitere Sicherheitsmaßnahmen. Erlaube GitHub Actions nur aus einer vom Unternehmen genehmigten Liste. Blockiere neue und nicht überprüfte Prozesse. Konfiguriere GITHUB_TOKEN und andere Zugriffsschlüssel nach dem Prinzip der geringsten Berechtigungen. Erteile nur dann Schreibrechte, wenn es gar nicht anders geht.

Für eine erhöhte Sicherheit von GitHub Actions stehen mehrere Open-Source-Tools zur Verfügung:

• zizmor – Tool zur statischen Analyse und Erkennung von Konfigurationsfehlern in GitHub Actions
• gato und Gato-X – zwei Versionen eines Tools, mit dem strukturell anfällige Pipelines identifiziert werden können
• allstar – eine von OpenSSF entwickelte GitHub-Anwendung zur Konfiguration und Durchsetzung von Sicherheitsrichtlinien in GitHub-Organisationen und Repositorys

Mehr Informationen über Kettenreaktionen bei Lieferkettenangriffen findest du in unserer Analyse Supply chain reaction: securing the global digital ecosystem in an age of interdependence. Sie basiert auf den Erkenntnissen von technischen Experten und zeigt, wie häufig Unternehmen mit Risiken in der Lieferkette und bei vertrauenswürdigen Beziehungen konfrontiert sind, wo Sicherheitslücken bestehen und welche Strategien ratsam sind, um die Widerstandsfähigkeit gegen diese Bedrohungen zu verbessern.