Trivy erneut angegriffen: Weitreichende Manipulation von GitHub-Actions-Tags führt zum Abfluss von Geheimdaten

• Die offizielle GitHub Action wurde per erzwungenem Tag-Update manipuliert, wodurch ein Supply-Chain-Angriff mit Auslieferung von Schadcode stattfand
• Die Angreifer ersetzten 75 von 76 Tags durch einen bösartigen Commit, wodurch etwa mehr als 10.000 Workflows betroffen waren
• Das manipulierte Skript arbeitet in drei Schritten: Sammeln, Verschlüsseln und Exfiltrieren von Geheimdaten; enthalten ist Code des TeamPCP Cloud stealer
• Die infizierten Tags sind weiterhin aktiv; als sicher gelten nur @0.35.0 oder eine bestimmte Commit-SHA
• Der Austausch sämtlicher Zugangsdaten sowie die Fixierung auf Commit-SHAs sind zwingend erforderlich; auch Docker-Hub-Images weisen dieselbe Kompromittierung auf

---

Überblick über den Supply-Chain-Angriff auf Trivy GitHub Actions

• Die offizielle GitHub Action von Trivy (aquasecurity/trivy-action) wurde von Angreifern durch erzwungene Tag-Updates (force-push) manipuliert, wodurch Schadcode verteilt wurde
• Die Angreifer ersetzten 75 von 76 Versionstags durch einen bösartigen Commit und sorgten so dafür, dass dieser in CI/CD-Pipelines automatisch ausgeführt wurde
• Da etwa mehr als 10.000 GitHub-Workflow-Dateien diese Action referenzieren, ist das Schadensausmaß erheblich
• Die infizierten Tags sind weiterhin aktiv; als einzige sichere Version gilt @0.35.0
• Socket erkannte ab 19:15 UTC in Echtzeit 182 bösartige GitHub-Action-Ereignisse und klassifizierte sie als Backdoor, Infostealer und Reconnaissance

Ursache und Ablauf des Angriffs

• Laut den Trivy-Maintainern wurde dieser Angriff durch den Diebstahl von Zugangsdaten mit Schreibrechten ermöglicht
  • Bei einem früheren Vorfall Anfang März wurden Secrets aus der CI-Umgebung offengelegt; bei der Rotation blieben einige neue Zugangsdaten unvollständig abgesichert und damit für die Angreifer verfügbar
  • Mit diesen Zugangsdaten führten die Angreifer authentifizierte Tag-Updates durch, ohne eine GitHub-eigene Schwachstelle auszunutzen
• Statt Branch-Pushes oder neuer Releases überschrieben die Angreifer bestehende Tags zwangsweise mit neuen Commits
  • Jeder Tag wurde so gefälscht, dass die Metadaten des ursprünglichen Commits übernommen wurden, also Autor, E-Mail, Zeitstempel und Commit-Nachricht, um legitim zu wirken
  • Allerdings waren die Original-Commits GPG-signiert, während bei den Commits der Angreifer die Signatur fehlte; zudem stimmte das Datum des Parent-Commits mit 2026 nicht überein
• Selbst wenn GitHub ein Release als Immutable Release kennzeichnet, könnten die Angreifer es zunächst im bösartigen Zustand veröffentlicht und erst danach gesperrt haben
  • Daher sollte man sich nicht auf das Badge „Immutable“ verlassen; nur das Pinning auf eine Commit-SHA ist eine sichere Nutzungsweise

Struktur der Tag-Manipulation

• Die Angreifer erzeugten neue Commits auf Basis des neuesten Commits des master-Branches (57a97c7e)
  • Dabei wurde nur die Datei entrypoint.sh durch eine bösartige Version ersetzt, während alle übrigen Dateien unverändert blieben
  • Für jeden Tag wurden ursprüngliche PR-Nummer, Commit-Nachricht und Autorendaten unverändert kopiert, um ihn zu fälschen
• Wenn auf der GitHub-Release-Seite „0 commits to master since this release“ angezeigt wird, kann das als visueller Hinweis auf ein manipuliertes Tag dienen
• Der Tag 0.35.0 wurde nur deshalb nicht manipuliert, weil er bereits auf den HEAD von master zeigte

Aufbau der bösartigen Payload

• Das manipulierte entrypoint.sh umfasst insgesamt 204 Zeilen; Zeile 4 bis 105 enthalten den Infostealer-Code, danach folgt regulärer Trivy-Scan-Code
• Der Schadcode besteht aus drei Phasen
  • Phase 1: Sammlung (Collection) — Extraktion von Geheimdaten aus dem Speicher laufender Prozesse und dem Dateisystem des Runners
  • Phase 2: Verschlüsselung (Encryption) — Verschlüsselung der gesammelten Daten mit AES-256-CBC und RSA-4096
  • Phase 3: Exfiltration (Exfiltration) — Übertragung an eine von den Angreifern kontrollierte Domain oder an das GitHub-Konto des Opfers

• Phase 1: Sammlung von Geheimdaten

  • Die Umgebungsvariablen der GitHub-Actions-Runner-Prozesse (Runner.Worker, Runner.Listener, runsvc, run.sh) werden aus /proc/<pid>/environ gelesen; dabei werden Einträge mit den Schlüsselwörtern env und ssh extrahiert
  • Auf GitHub-gehosteten Runnern wird per sudo ein Python-basiertes Memory-Dump-Skript ausgeführt, das den Speicher des Runner.Worker-Prozesses nach dem Muster "isSecret":true durchsucht
  • Auf selbstgehosteten Runnern wird ein Dateisystem-basierter Credential-Stealer ausgeführt, der als TeamPCP Cloud stealer identifiziert wurde
    • Ziele sind unter anderem SSH-Schlüssel, AWS-/GCP-/Azure-Zugangsdaten, Kubernetes-Tokens, Docker-Konfigurationen, DB-Passwörter, Environment-Dateien, TLS-Schlüssel, VPN-Konfigurationen, Webhook-URLs und Wallet-Schlüssel

• Phase 2: Verschlüsselung

  • Mit openssl rand wird ein 32-Byte-Session-Key erzeugt, anschließend werden die Daten mit AES-256-CBC verschlüsselt
  • Der Session-Key wird mit einem öffentlichen RSA-4096-Schlüssel unter Verwendung von OAEP-Padding verschlüsselt
  • Die verschlüsselten Daten (payload.enc) und der Session-Key (session.key.enc) werden als tpcp.tar.gz gebündelt

• Phase 3: Datenexfiltration

  • Primärer Kanal: HTTPS-POST an https://scan[.]aquasecurtiy[.]org unter Verwendung einer Tippfehler-Domain von aquasecurity
  • Sekundärer Kanal: Falls dies fehlschlägt, wird mit dem GitHub Personal Access Token des Opfers ein öffentliches Repository namens tpcp-docs erstellt
    • tpcp.tar.gz wird als Release-Asset hochgeladen → die Angreifer finden das Repository anschließend über die GitHub-Suche und sammeln die Daten ein
  • Durch die Nutzung der GitHub-Infrastruktur wird versucht, Firewalls zu umgehen; die Wahrscheinlichkeit einer Umgehung der Erkennung ist hoch
  • Zum Schluss werden temporäre Dateien gelöscht, um Spuren zu minimieren

Angreifer und Hintergründe

• In Kommentaren des Schadcodes wird ausdrücklich „TeamPCP Cloud stealer“ genannt
  • TeamPCP (DeadCatx3, PCPcat, ShellForce) ist eine Angreifergruppe für Cloud-native Umgebungen, die unter anderem Docker-API-, Kubernetes-, Redis- und Ray-Dashboard-Schwachstellen ausgenutzt hat
  • Im Februar 2026 wurde die Gruppe von Flare und The Hacker News mit Kampagnen zu Ransomware, Datendiebstahl und Krypto-Mining in Verbindung gebracht
• Die Funktionen zum Sammeln von Solana-Validator-Schlüsseln und Krypto-Wallets passen zu einem finanziellen Motiv

Reaktion und Empfehlungen

• Keine Trivy-Action-Versionstags mehr verwenden; ausschließlich die Commit-SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 oder den Tag 0.35.0 nutzen
• Betroffene Pipelines sollten als vollständiger Abfluss von Geheimdaten betrachtet werden; sämtliche Cloud-Zugangsdaten, SSH-Schlüssel, API-Tokens, DB-Passwörter und Docker-Tokens müssen sofort ausgetauscht werden
• Es wird empfohlen, innerhalb der GitHub-Organisation auf ein Repository tpcp-docs zu prüfen und Logs von trivy-action-Ausführungen nach dem 19. März, 19:00 UTC, zu überprüfen

Indicators of Compromise (IOCs)

• Netzwerkindikator: scan[.]aquasecurtiy[.]org
• Datei-Hash: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
• Infizierte GitHub Actions: alle Versionen von aquasecurity/trivy-action@0.0.1 bis @0.34.2 (insgesamt 75 Tags)

Weiteres Update (22. März)

• Auch auf Docker Hub wurde bestätigt, dass Trivy-Images (0.69.4, 0.69.5, 0.69.6, latest) mit derselben Infostealer-Payload kompromittiert wurden
• Das Tag latest zeigte auf ein bösartiges Image und wurde während des Expositionszeitraums an Nutzer ausgeliefert
• Weitere Details finden sich im separaten Bericht von Socket „Trivy Docker Images Compromised“

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, warum GitHub für Actions keine unveränderliche Versionsverwaltung (immutable versioning) erzwingt.
  Die Sicherheitsleitlinien empfehlen, auf einen Commit-SHA zu pinnen, aber wenn man eine Action ohne Pinning gar nicht erst veröffentlichen könnte, ließe sich so etwas vermutlich reduzieren.

  • Solche Diskussionen haben immer zwei Seiten.
    Aus Sicht des Sicherheitsteams sind festgepinnte Versionen sicherer, aber gleichzeitig ist es auch riskant, wenn Sicherheitsupdates nicht automatisch übernommen werden.
    Am Ende braucht es eine Lösung, die beides erfüllt, ohne die Produktivität zu beeinträchtigen.
    Ich würde das das „Paradox des Pinnings“ nennen.
  • Ich denke, dass GitHub Actions dem Git-Tag-Modell folgt und sich die aktuelle Struktur deshalb nur schwer ändern lässt.
    Trotzdem muss man irgendwann anfangen, das zu ändern.
  • Was wäre, wenn die festgepinnte Version bereits kontaminiert gewesen wäre?
    Updates zuzulassen könnte die Sicherheit sogar erhöhen.
    Das ist ein ähnliches Problem wie die Debatte über statisches vs. dynamisches Linken.
    Außerdem war die Trivy Action ohnehin so gebaut, dass sie die neueste Version holt.

• Dieser Vorfall ist eine Warnung, dass Produkte für „Supply-Chain-Sicherheit“ in der Praxis genauso verwundbar sein können wie der Stack, den sie schützen sollen.
  Gerade Sicherheitswerkzeuge, die nach dem Motto „run us everywhere“ überall laufen, schaffen einen neuen Angriffsvektor, bei dem ein einzelner Angriff unzählige Nutzer gleichzeitig gefährden kann.

• Zuerst dachte ich, Trivy hätte die Rotation von Zugangsdaten nicht sauber durchgeführt.
  Aber sie erklärten, dass ein Angreifer im Zuge eines „nicht-atomaren“ Rotationsprozesses womöglich das neue Token erfahren haben könnte.
  GitHub zeigt Tokens nach der Ausstellung normalerweise nicht erneut an, aber je nach Authentifizierungsmethode kann das unterschiedlich sein.

  • Der Ersteller von OpenClaw sagte, er habe etwas Ähnliches erlebt.
    Unmittelbar nach dem Anlegen einer neuen GitHub-Organisation sei der Name übernommen worden, sodass er GitHub um eine atomare Erstellung bitten musste.

• Das ist ein Vorfall, auf den der Satz „Man sollte Schwachstellen scannen, nicht selbst eine sein“ perfekt passt.

  • Es gab sogar den Witz: „Wenn du lange genug in eine Schwachstelle blickst, blickt die Schwachstelle auch in dich hinein“.

• Als verwandten Vorfall gab es eine vorübergehende Beeinträchtigung der Trivy-Supply-Chain.

  • Die Formulierung „vorübergehend“ wirkt wie eine allzu beschönigende Umschreibung.

• Am 22. März veröffentlichte der Angreifer mit kompromittierten Zugangsdaten bösartige Trivy-v0.69.5- und v0.69.6-DockerHub-Images
  (Link zur Sicherheitsmeldung).
  Es gab zwei Vorfälle, am 19. und am 22. März, und der Angreifer scheint sich trotz zweier Rotationen der Zugangsdaten dauerhaft Zugriff erhalten zu haben.

  • Tatsächlich gab es wohl schon seit Februar eine vollständige Repository-Kompromittierung, und dies war der dritte erfolgreiche Angriff desselben Akteurs.

• „Die letzten zwei Wochen waren die schlimmsten.“
  Wegen der Kompromittierung von Trivy muss man jetzt unzählige Sicherheitsberichte und Meetings bewältigen.

• Die Lehre daraus ist: „Nur weil jemand Sicherheitssoftware baut, heißt das nicht, dass er kompetent ist.“
  Auch unser Sicherheitsteam versucht jeden Monat, einen neuen Scanner einzuführen, aber wenn wir den von ihnen geforderten weitreichenden Zugriff zugelassen hätten, wären wir wahrscheinlich schon mehrfach kompromittiert worden.

  • Ich habe die GitHub Actions von Trivy früher einmal auditiert, und die setup-trivy-Action war so aufgebaut, dass sie einfach den Main-Branch klont und ein Shell-Skript ausführt.
    Damit war in jedem CI-Workflow eine Ausführung beliebigen Codes möglich.
    Aqua wurde Anfang dieses Monats kompromittiert, scheiterte zweimal an der Isolierung, und am Ende wurde sogar das Docker-Hub-Konto übernommen.
    Ich denke, jetzt braucht man Hilfe von externen Experten.
  • „Sicherheitswerkzeugen“ weitreichende Zugriffsrechte zu geben, reduziert kein Risiko, sondern vervielfacht es.
    Die meisten sind nur laute Berichtsgeneratoren, und wenn ein Angreifer einmal drin ist, können sie überhaupt nichts mehr verteidigen.
    Neue Scanner sollten nur in einer isolierten Sandbox mit schreibgeschütztem Zugriff auf Daten laufen und keine Produktionsrechte bekommen, bis sie ausreichend verifiziert wurden.
    Andernfalls ist das kaum etwas anderes, als geheime Schlüssel auf pastebin hochzuladen.
  • Unternehmenssicherheit besteht heute oft darin, auf allen Geräten Endpoint-Security-Lösungen zu installieren und sämtliche Logs an ein AI-Dashboard zu schicken.
    Es ist zu einer Sicherheitskultur geworden, die „sich schnell bewegt und dabei alles kaputtmacht“.
  • In Sicherheitsabteilungen gibt es faktisch keine Option nach dem Motto: „Es gibt kein brauchbares Produkt am Markt, also verwenden wir gar nichts.“
    Dadurch entsteht eine Kultur, in der selbst minderwertige Sicherheitssoftware zwangsläufig eingeführt wird.
    Ich halte Trivy selbst nicht für schlecht, und wir nutzen es auch im Unternehmen.
    Allerdings pinnen wir die Version mit Nix und schreiben unsere Actions-Workflows selbst, sodass wir von dieser Kompromittierung nicht betroffen waren.

• Der Angreifer konnte im authentifizierten Zustand Tags per Force-Update überschreiben.
  Das wäre allein durch Aktivierung der alten GitHub-Einstellung „Überschreiben von Tags verbieten“ verhindert worden.
  Je häufiger sich solche Vorfälle wiederholen, desto stärker denke ich, dass wir Standards wie eine Software Building Code brauchen.
  Ich frage mich, wie viele weitere Gründe dieser Art bis 2026 noch dazukommen werden.