Der Trivy Supply-Chain-Angriff traf Entwickler und CI/CD-Pipelines, weil Angreifer nach einer früheren Credential-Exfiltration in der Lieferkette blieben, am 19. März 2026 offizielle Tags und Releases umbogen und einen Infostealer vor dem eigentlichen Scan ausführen ließen. Damit wirkten kompromittierte Workflows auf den ersten Blick normal, obwohl Secrets bereits abgegriffen werden konnten.
Trivy Supply-Chain-Angriff trifft Releases, Actions und Vertrauenskette
Der Trivy Supply-Chain-Angriff entstand nicht durch eine gewöhnliche Schwachstelle, sondern durch die offizielle Lieferkette. Betroffen waren nicht nur einzelne Artefakte, sondern der Release trivy v0.69.4 sowie die beiden GitHub Actions aquasecurity/trivy-action und aquasecurity/setup-trivy. Risiko: Wer Trivy automatisiert in Build- und Scan-Strecken eingebunden hatte, konnte auf formal unveränderte Versionsangaben vertrauen und dennoch unbemerkt Schadcode ausführen.
Nach dem Sicherheits-Advisory von Aqua auf GitHub nutzte ein Angreifer am 19. März 2026 kompromittierte Zugangsdaten, um den offiziellen Release trivy v0.69.4 zu veröffentlichen, 76 von 77 Versions-Tags in trivy-action auf bösartige Commits umzubiegen und alle sieben Tags in setup-trivy zu ersetzen. Der besonders heikle Punkt liegt darin, dass nicht nur eine neue, verdächtige Version eingeschleust wurde. Die Täter schrieben bereits bekannte und in vielen Pipelines verwendete Tags um. Workflows, die auf @0.x.y vertrauten statt auf einen festen Commit-SHA, konnten so beim nächsten Lauf kompromittierten Code nachladen, ohne dass sich die Referenz im Workflow selbst sichtbar geändert hätte.
Wie der Trivy Supply-Chain-Angriff entstehen konnte
Die inzwischen wichtigste neue Erkenntnis ist, dass der Vorfall vom 19. März nicht aus dem Nichts kam. Laut dem aktuellen Lagebild von Aqua begann die Angriffskette bereits Ende Februar 2026. Damals nutzten Angreifer eine Fehlkonfiguration in Trivys GitHub-Actions-Umgebung aus, erbeuteten einen privilegierten Zugangstoken und verschafften sich damit Zugriff auf Automations- und Release-Prozesse. Aqua beschreibt diesen Ursprung bislang bewusst allgemein als Fehlkonfiguration. Sicherheitsanalysen aus der Community und von Incident-Response-Seite führen die erste Eintrittskette technischer auf ein riskantes pull_request_target-Szenario zurück, bei dem öffentliche Repositories extern ausgelöste Workflows mit erhöhten Rechten ausführen können.
Entscheidend für den späteren Schaden war anschließend die nicht vollständig abgeschlossene Bereinigung nach dem ersten Incident vom 1. März. Aqua schreibt offen, dass Secrets und Tokens zwar rotiert wurden, der Vorgang aber nicht atomar verlief. Genau daraus entstand ein mehrtägiges Fenster, in dem der bereits eingedrungene Angreifer neu ausgegebene oder noch nicht gleichzeitig widerrufene Zugangsdaten erneut erfassen konnte.
So lief die zweite Phase des Trivy Supply-Chain-Angriffs ab
Am 19. März nutzten die Täter diesen Restzugriff, um die offizielle Vertrauenskette direkt zu missbrauchen. Die auffällige Aktivität begann (GTM+1) gegen 18:43 Uhr mit den manipulierten Actions-Tags. Der kompromittierte Release trivy v0.69.4 war laut Aqua ungefähr zwischen 19:22 Uhr und 22:42 Uhr öffentlich erreichbar. Für setup-trivy endete das Expositionsfenster noch am selben Abend gegen 22:44 Uhr, während trivy-action bis zum 20. März gegen 06:40 Uhr betroffen blieb. Diese konkreten Zeitfenster sind operativ relevant, weil sich damit GitHub-Workflow-Runs, Artefakte und Runner-Logs sehr gezielt eingrenzen lassen.
Technisch lief der Angriff in mehreren Schritten. Beim Release von trivy v0.69.4 wurde ein manipulierter Commit so vorbereitet, dass statt des legitimen Codes ein schädlicher Bestandteil aus einer typosquatteten Domain nachgeladen werden konnte; zusätzlich wurde laut Advisory die Validierung in der Release-Kette umgangen. Noch gefährlicher war die Tag-Manipulation in den GitHub Actions. Dort genügte den Angreifern Schreibzugriff, um Tags per Force-Push auf andere Commits zeigen zu lassen. Genau diesen Mechanismus beschreibt auch eine technische Analyse von CrowdStrike: Git-Tags sind bequem, aber veränderlich. Das macht sie als Versionsanker für CI/CD bequem, aber aus Sicht der Lieferkettensicherheit angreifbar.
Warum Entwickler und Pipelines den Angriff kaum bemerkten
Die eingeschleuste Malware war so platziert, dass sie vor dem eigentlichen Trivy-Scan anlief. Das ist der Grund, warum viele betroffene Workflows äußerlich normal wirken konnten. Der Job lieferte weiterhin ein vermeintlich reguläres Scannergebnis, während im Hintergrund sensible Daten aus dem Runner-Speicher und dem Dateisystem gesammelt wurden. Aqua nennt unter anderem SSH-Schlüssel, AWS-, GCP- und Azure-Credentials, Kubernetes-Tokens, Docker-Konfigurationen, .env-Dateien, Git-Zugangsdaten und Datenbank-Credentials. Wer in diesem Fenster betroffen war, darf einen grünen Pipeline-Run deshalb nicht als Entwarnung missverstehen.
Hinzu kam ein Fallback für die Datenabfuhr. Wenn die direkte Exfiltration fehlschlug und ein geeignetes GitHub-Token vorhanden war, sollte die Malware nach Aquas Beschreibung ein öffentliches Repository namens tpcp-docs im Konto des Opfers anlegen und die gesammelten Daten dort als Release-Asset ablegen.
Im Rahmen der Vorfallsbehandlung sollten hier, GitHub-Audit-Logs, neu angelegte Repositories, Release-Artefakte und Bot-Aktivitäten in Organisationskonten untersucht werden.
Der Trivy Supply-Chain-Angriff endete nicht beim Secret-Diebstahl
Der Trivy-Vorfall endete nicht beim Diebstahl von CI/CD-Secrets. Nach aktuellen Analysen hinterließ die kompromittierte Angriffskette auf betroffenen Entwickler-Systemen und Runnern zusätzliche Persistenz, sodass das Risiko weit über den eigentlichen Pipeline-Run hinausging. CrowdStrike beschreibt, dass die Malware vor dem legitimen Trivy-Scan anlief und so unauffällig Credentials abgreifen konnte, während Aqua den Angriff als mehrstufige Kampagne einordnet, deren Ursprung bereits Ende Februar in einer Kompromittierung der GitHub-Actions-Umgebung lag.
Besonders brisant ist die zweite Eskalationsstufe: Die nachgelagerte Infrastruktur setzte laut den vorliegenden Analysen auf einen ICP-basierten Dead-Drop-Mechanismus, über den kompromittierte Systeme weitere Nutzlasten nachladen konnten. Parallel dazu sprang die Kampagne auf das npm-Ökosystem über: Wie The Hacker News unter Verweis auf technische Analysen berichtet, wurden im Rahmen des sogenannten CanisterWorm mindestens 47 npm-Pakete kompromittiert; deren postinstall-Hooks suchten nach Tokens, luden weitere Schadkomponenten nach und nutzten kompromittierte Publisher-Rechte zur weiteren Verbreitung. Damit wurde aus einem Supply-Chain-Angriff auf Trivy eine deutlich breitere, sich fortpflanzende Ökosystem-Bedrohung.
Welche Versionen betroffen waren und was jetzt als sicher gilt
Als kompromittiert gelten trivy v0.69.4, bei trivy-action alle Tags von 0.0.1 bis 0.34.2 und bei setup-trivy sämtliche Tags von v0.2.0 bis v0.2.6. Als sichere Zielstände nennt Aqua trivy v0.69.3, trivy-action 0.35.0 und setup-trivy 0.2.6. Nicht betroffen waren Umgebungen, die Container per Digest statt per Tag bezogen oder GitHub Actions bereits auf volle Commit-SHAs gepinnt hatten.
Trivy Supply-Chain-Angriff – Lessons Learned
Die operative Sofortmaßnahme bleibt eindeutig: jede Pipeline, die in den genannten Zeitfenstern eine betroffene Version ausgeführt hat, sollte als potenziell kompromittiert behandelt werden. Das bedeutet Secret-Rotation ohne Ausnahme, inklusive Cloud-Keys, Registry-Tokens, Deploy-Schlüsseln, GitHub-Tokens und aller weiteren Zugangsdaten, die auf Runnern verfügbar waren. Bei Self-hosted Runnern reicht das reine Update ohnehin nicht aus, weil dort zusätzliche lokale Dateien und Zugangsinformationen abgegriffen worden sein können.
Strategisch ist der Fall ebenso unangenehm wie lehrreich. Ein Sicherheitswerkzeug wurde selbst zum Verteilkanal eines Infostealers, weil ein früher gestohlener Token, eine unvollständige Bereinigung und das Vertrauen auf mutable Tags zusammenkamen. Der Trivy Supply-Chain-Angriff zeigt damit exemplarisch, dass moderne Software-Lieferketten nicht nur auf Schwachstellen geprüft, sondern gegen Missbrauch der eigenen Automationsrechte gehärtet werden müssen. Wer daraus nur die Lesson „auf die nächste saubere Version aktualisieren“ zieht, greift zu kurz. Die eigentliche Konsequenz: GitHub Actions auf Commit-SHAs pinnen, Token-Rechte drastisch reduzieren, Rotationen vollständig und gleichzeitig durchführen und CI/CD-Runner wie kritische Produktionssysteme überwachen.
Die oft genannte Zuordnung zu TeamPCP bleibt dabei ein Nebenaspekt. Für die Verteidigung ist im Moment wichtiger, dass Ursache, Ablauf und betroffene Versionen inzwischen belastbar beschrieben sind. Der Fall ist vor allem deshalb bemerkenswert, weil er zeigt, wie schnell ein Angriff auf die Build- und Release-Ebene aus einem Sicherheitswerkzeug selbst ein Risiko für Entwickler, Organisationen und nachgelagerte Lieferketten macht.
