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\u00fcrdigen L\u00f6sungen wurden j\u00fcngst zum Ausgangspunkt f\u00fcr einen der gr\u00f6\u00dften und gef\u00e4hrlichsten Lieferkettenangriffe des digitalen Zeitalters. Unsere Fragen in diesem Artikel: Wie werden automatisierte Workflows \u00fcberpr\u00fcft? Und wie l\u00e4sst sich die Cloud-Infrastruktur eines Unternehmens sch\u00fctzen?<\/p>\n
Am 19. M\u00e4rz wurde \u00fcber Trivy erfolgreich ein gezielter Lieferkettenangriff ausgef\u00fchrt. Trivy ist ein Open-Source-Tool zur Schwachstellensuche, das f\u00fcr CI\/CD-Pipelines sehr beliebt ist. Den Angreifern (einer als \u201eTeamPCP\u201c 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\u00fcssel, Token f\u00fcr 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<\/a> und erreichte fast den maximalen CVSS4B-Score von 9,4.<\/p>\n Das Trivy-Team erkannte den Angriff noch am selben Tag und entfernte b\u00f6sartige Artefakte aus den Distributionskan\u00e4len. Damit war diese Angriffsphase gestoppt. In der Zwischenzeit hatten die Angreifer sich jedoch schon Zugriff auf die Umgebungen vieler Trivy-Nutzer verschafft.<\/p>\n Am 23. M\u00e4rz wurde ein \u00e4hnlicher Vorfall<\/a> in einem anderen Tool f\u00fcr Anwendungssicherheit entdeckt: in einer GitHub Action f\u00fcr Checkmarx KICS sowie Checkmarx AST. Drei Stunden sp\u00e4ter wurde der Schadcode auch von dort entfernt. TeamPCP landete jedoch einen weiteren Treffer und kompromittierte die von Checkmarx unterst\u00fctzten OpenVSX-Erweiterungen <\/a>cx-dev-assist<\/em> 1.7.0 und ast-results<\/em>. Es gibt unterschiedliche Angaben dar\u00fcber, wann dieser Teil des Vorfalls behoben wurde.<\/p>\n Am 24. M\u00e4rz wurde LiteLLM AI Gateway angegriffen, ein popul\u00e4res Projekt, das die Code-Untersuchung von Trivy verwendet und als universelle Bibliothek f\u00fcr 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\u00fcnf Stunden lang \u00f6ffentlich verf\u00fcgbar.<\/p>\n Obwohl der Angriff nur wenige Stunden dauerte, darf der Vorfall nicht untersch\u00e4tzt werden. Angesichts der Beliebtheit der betroffenen Projekte k\u00f6nnte der b\u00f6sartige Code tausende Male ausgef\u00fchrt worden sein, darunter auch in der Infrastruktur sehr gro\u00dfer Unternehmen.<\/p>\n Die Angreifer konnten persistente Backdoors in Kubernetes-Clustern einbauen und den sich selbst replizierenden CanisterWorm<\/a> im JavaScript-npm-\u00d6kosystem starten.<\/p>\n Der Code der Angreifer verf\u00fcgt \u00fcber destruktive F\u00e4higkeiten<\/a>, die einen Kubernetes-Cluster und alle seine Knoten l\u00f6schen, wenn er Teheran als Zeitzone oder Farsi als prim\u00e4re Sprache auf dem kompromittierten System erkennt. In anderen Regionen begn\u00fcgt sich die Malware mit dem Diebstahl von Daten. Dies erledigt CanisterWorm.<\/p>\n Experten zufolge gelten mehr als 20.000 Repositorys als potenziell anf\u00e4llig. Die Angreifer behaupten, Hunderte Gigabyte an Daten und mehr als eine halbe Million Accounts<\/a> gestohlen zu haben.<\/p>\n Zur Kompromittierung von Trivy verwendeten die Angreifer Anmeldeinformationen, die sie schon fr\u00fcher gestohlen hatten. Der vorhergehende Trivy-Vorfall<\/a> fand Ende Februar statt und konnte offenbar nicht vollst\u00e4ndig einged\u00e4mmt 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<\/a> jedoch, dass die Angreifer neue Zugriffstoken generierten, bevor alle kompromittierten Token gesperrt wurden.<\/p>\n Darum gelang es TeamPCP, GitHub Actions zu kompromittieren, die in CI\/CD-Pipelines eingesetzt wurden. Die Angreifer verf\u00fcgten \u00fcber Anmeldedaten mit Schreibrechten f\u00fcr Tags. Sie \u00fcberschrieben 76 von 77 Versions-Tags in aquasecurity\/trivy-action sowie alle sieben Tags in aquasecurity\/setup-trivy und leiteten vorhandene vertrauensw\u00fcrdige Versionen in b\u00f6sartige Commits um. Eine \u00e4hnliche Taktik wurde in der Kampagne von Shai-Hulud 2.0<\/a> beobachtet. Daraufhin wurden in den Workflows der gesamten Pipeline b\u00f6sartiger Code ausgef\u00fchrt, w\u00e4hrend in den Release-Metadaten keine verd\u00e4chtigen \u00c4nderungen bemerkbar waren.<\/p>\n Gleichzeitig ver\u00f6ffentlichten die Angreifer eine infizierte Trivy-Bin\u00e4rdatei (v0.69.4) in offiziellen Distributionskan\u00e4len, darunter bei GitHub Releases und in Container-Registern.<\/p>\n Eine Kompromittierung von LiteLLM, eines beliebten Zugriffstools f\u00fcr Sprachmodelle, konnte eine umfangreiche Angriffswelle auf die gesamte Kette der betroffenen Projekte ausl\u00f6sen. Der Angriff ereignete sich am 24. M\u00e4rz 2026: TeamPCP ver\u00f6ffentlichte sch\u00e4dliche 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<\/em> eingebettet, und Version 1.82.8 enthielt zudem die b\u00f6sartige Datei litellm_init<\/em>. Die gestohlenen Daten wurden auf den Server models.litellm[.]cloud<\/em> abgesch\u00f6pft.<\/p>\n 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 \u00fcber pip installierten, wurden dagegen kompromittiert.<\/p>\n Innerhalb von drei Stunden wurden die b\u00f6sartigen 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<\/em> zu suchen und alle potenziell kompromittierten Geheimnisse routinem\u00e4\u00dfig zu rotieren.<\/p>\n Die Angreifer f\u00fcgten GitHub Actions und der ausf\u00fchrbaren Trivy-Datei eine neue Logik hinzu, w\u00e4hrend die urspr\u00fcngliche Funktionalit\u00e4t beibehalten wurde. Die Ergebnisse des Trivy-Schwachstellen-Scans schienen normal zu sein. Gleichzeitig wurden jedoch wertvolle Daten gesucht und extrahiert. Der b\u00f6sartige Code stellte Folgendes an:<\/p>\n Die gesammelten Daten wurden verschl\u00fcsselt und auf einen Server mit einem \u00e4hnlichen Namen wie dem der Trivy-Entwickler hochgeladen (scan.aquasecurtiy[.]org<\/em>). Als Backup-Mechanismus stellten die Angreifer die Methode docs-tpcp<\/em> f\u00fcr den Daten-Upload in ein Repository bereit.<\/p>\n Der Angriff auf CheckMarx und LiteLLM nutzte eine \u00e4hnliche Taktik mit anderen Typosquatting-Dom\u00e4nen: models.litellm[.]cloud<\/em> und checkmarx[.]zone<\/em>.<\/p>\n Eine detaillierte technische Analyse der Malware sowie die Kompromittierungsindikatoren findest du in unserem Expertenartikel im Securelist-Blog<\/a>.<\/p>\n Die bestehenden signaturbasierten Pr\u00fcfungen und die Abh\u00e4ngigkeitsuntersuchung in \u00f6ffentlichen Registern reichen nicht mehr aus, da der b\u00f6sartige Code direkt in vertrauensw\u00fcrdige, signierte Aktionen eingeschleust wurde und erst durch Verhaltens\u00fcberwachung enttarnt werden konnte. CI\/CD-Pipelines sind zum \u201eneuen Perimeter\u201c der Sicherheit geworden.<\/p>\n Dringende Ma\u00dfnahmen. <\/strong>\u00dcberpr\u00fcfe, ob alle Workflows sichere Versionen verwenden (Trivy-Binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).<\/p>\n Administratoren von CI\/CD-Pipelines und Sicherheitsteams sollten die Abh\u00e4ngigkeiten der L\u00f6sungen von Checkmarx (kics-github-action, ast-github-action) und Trivy (setup-trivy und trivy-action) sofort \u00fcberpr\u00fcfen. Wenn Workflows auf ein Versions-Tag verwiesen haben (anstatt auf einen bestimmten SHA-Hash), m\u00fcssen die Workflow-Ausf\u00fchrungsprotokolle f\u00fcr den Zeitraum des aktiven Lieferkettenangriffs sorgf\u00e4ltig \u00fcberpr\u00fcft werden.<\/p>\n Zudem solltest du einen genauen Blick in die Netzwerkprotokolle werfen. Gab es Datenverkehr zu den Dom\u00e4nen scan.aquasecurtiy[.]org<\/em>, checkmarx[.]zone<\/em> und models.litellm[.]cloud<\/em>? Wenn ja, so wurden sensible Daten erfolgreich exfiltriert.<\/p>\n Wenn auf dem Unternehmens-GitHub ein Repository namens docs-tpcp aufgetaucht ist, kann dies ebenfalls auf einen erfolgreichen Datendiebstahl hinweisen.<\/p>\n \u00dcberpr\u00fcfe Hosts und Cluster auf Kompromittierungsspuren: Gibt es Dateien wie ~\/.config\/sysmon\/sysmon.py oder verd\u00e4chtige Pods in Kubernetes?<\/p>\n Leere den Cache und f\u00fchre eine Inventarisierung der PyPI-Module durch: Suche nach b\u00f6sartigen Modulen und setze auf saubere Versionen zur\u00fcck.<\/p>\nWie Trivy angegriffen wurde<\/h2>\n
Kompromittierung von LiteLLM<\/h2>\n
Funktionen der Stealer-Malware TeamPCP Cloud<\/h2>\n
\n
Reaktionen und Abwehrstrategien f\u00fcr CVE-2026-33634<\/h2>\n