Am 19. März 2026 wurde Trivy, einer der meistgenutzten Open-Source-Vulnerability-Scanner, selbst zum Angriffsvektor. Eine Gruppe namens TeamPCP kompromittierte das GitHub-Repository von Aqua Security, vergiftete 75 von 76 Release-Tags der trivy-action und schleuste Malware in CI/CD-Pipelines weltweit ein. Was danach folgte, war ein mehrstufiger Supply-Chain-Angriff, der bis in npm-Pakete hineinreichte und sich dort selbstständig weiterverbreitete.
Was genau passiert ist
Der Angriff lief in klar abgrenzbaren Phasen ab. Zunächst verschafften sich die Angreifer Zugang zum Service-Account aqua-bot und nutzten gestohlene Credentials, um direkte Commits ins Trivy-Repository zu pushen. Dabei setzten sie auf Impersonation: Die Commits trugen die Identität legitimer Maintainer, was die Erkennung erschwerte.
Am 19. März um 17:43 UTC pushten die Angreifer manipulierten Code auf den Tag v0.69.4 und triggerten damit ein automatisches Release. Innerhalb weniger Stunden waren manipulierte Binaries über GitHub Releases, Docker Hub, GHCR und ECR verteilt. Parallel dazu wurden 75 der 76 Version-Tags in aquasecurity/trivy-action per Force-Push auf schadhafte Commits umgebogen.
Das Perfide daran: Wer in seiner CI/CD-Pipeline trivy-action@v1 oder einen ähnlichen Tag referenzierte, bekam von einem Moment auf den nächsten kompromittierten Code, ohne dass sich an der eigenen Workflow-Datei etwas geändert hatte.
Wie Credentials aus CI/CD-Runnern gestohlen wurden
Die eingeschleuste Malware verfolgte ein dreistufiges Exfiltrationsmodell. Im ersten Schritt durchsuchte sie den Prozessspeicher der GitHub Actions Runner unter /proc/<pid>/mem nach Mustern wie {"value":"<secret>","isSecret":true}. Diese Methode umging das Log-Masking, das GitHub für Secrets einsetzt.
Danach durchkämmte die Malware über 50 bekannte Dateipfade auf dem Runner-Filesystem: SSH-Keys, AWS-Credentials, GCP-Service-Account-Tokens, Azure-Konfigurationen, Kubernetes-Kubeconfigs und sogar Crypto-Wallet-Dateien.
Die gesammelten Daten wurden hybrid verschlüsselt (AES-256-CBC plus RSA-4096) und an eine Typosquatting-Domain exfiltriert: scan.aquasecurtiy.org. Als Fallback legte die Malware ein Repository namens tpcp-docs in den GitHub-Organisationen der Opfer an.
## Verwundbare Pipeline-Konfiguration (NICHT verwenden)
- uses: aquasecurity/trivy-action@v1 # Tag-basiert = angreifbar
with:
image-ref: 'myapp:latest'
## Sichere Alternative: SHA-Pinning
- uses: aquasecurity/trivy-action@a1c56d356830a78f10e39120e89bb5c383764f46
with:
image-ref: 'myapp:latest'Der Unterschied: Ein Tag wie @v1 ist ein bewegliches Ziel. Ein Force-Push ändert, worauf er zeigt, ohne Spuren zu hinterlassen. Ein SHA-Hash dagegen ist kryptografisch an einen bestimmten Commit gebunden. Selbst mit vollem Repository-Zugriff lässt sich der referenzierte Code nicht austauschen.
Der CanisterWorm: Vom CI-Runner ins npm-Ökosystem
Die gestohlenen Credentials ermöglichten den nächsten Eskalationsschritt. Mit erbeuteten npm-Tokens infizierten die Angreifer zunächst 47 npm-Pakete, die sich später auf 141 schadhafte Artefakte über 66 Pakete ausweiteten. Betroffen waren unter anderem Pakete aus den Scopes @EmilGroup und @opengov.
Die Malware, die Forscher als CanisterWorm bezeichneten, nutzte einen ungewöhnlichen Command-and-Control-Kanal: Internet Computer Protocol (ICP) Canisters. Ein als PostgreSQL-Monitoring getarnter systemd-Service (pgmon) polte alle 50 Minuten einen ICP-Canister nach neuen Payload-URLs.
Das Besondere: Der Wurm propagierte sich selbst weiter. Spätere Varianten ernteten npm-Authentifizierungs-Tokens aus Entwicklerumgebungen und nutzten ein deploy.js-Skript, um jedes erreichbare Paket automatisch zu infizieren. Ein klassischer Wurm-Mechanismus, nur eben im Paketmanager-Ökosystem.
Warum dieser Angriff anders ist
Supply-Chain-Angriffe sind nicht neu. SolarWinds (2020), Codecov (2021), ua-parser-js (2021): Jeder dieser Vorfälle kompromittierte einzelne Komponenten. Der Trivy-Angriff kombinierte erstmals Binary-Tampering, Tag-Poisoning, persistente Backdoors und einen sich selbst verbreitenden Wurm in einer koordinierten Kampagne.
Das eigentlich Beunruhigende ist die Vertrauensasymmetrie. Security-Tools wie Trivy laufen mit erhöhten Privilegien und werden selten selbst überwacht. Wer einen Vulnerability-Scanner kompromittiert, bekommt Zugriff auf Credentials, Deployment-Tokens und Environment-Variablen aller Projekte, die diesen Scanner einsetzen. Aus einem Verteidigungswerkzeug wird ein Angriffsvektor mit maximalem Blast Radius.
Konkrete Schutzmaßnahmen für Teams
Aus dem Trivy-Vorfall lassen sich direkte Handlungsempfehlungen ableiten, die über das Offensichtliche hinausgehen.
SHA-Pinning für alle GitHub Actions ist der wichtigste erste Schritt. Statt @v1 oder @latest gehört der vollständige Commit-Hash in die Workflow-Datei. Tools wie StepSecurity Harden-Runner automatisieren diesen Prozess.
Postinstall-Hooks in npm deaktivieren. In CI-Pipelines sollte npm install --ignore-scripts Standard sein, kombiniert mit einer expliziten Allowlist für Pakete, die Build-Skripte benötigen. Das blockiert den primären Infektionsvektor des CanisterWorm.
## npm-Installation ohne automatische Skripte
npm install --ignore-scripts
## Nur explizit erlaubte Pakete duerfen Skripte ausfuehren
npx --package=@pnpm/allow-scripts allow-scriptsSecrets-Rotation nach Verdacht. Jedes Team, das zwischen dem 19. und 23. März Trivy in CI/CD-Pipelines genutzt hat, sollte sämtliche Secrets rotieren: API-Keys, Deployment-Tokens, SSH-Keys, Cloud-Credentials. Die offizielle Aqua Security Advisory listet betroffene Versionen und Indikatoren.
Runtime-Monitoring auf Runnern. Das Erstellen unbekannter systemd-Services, Netzwerkverbindungen zu ICP-Endpoints und das Lesen von /proc/*/mem sind starke Indikatoren für eine Kompromittierung. Wer seine CI/CD-Security ernst nimmt, integriert diese Signale in das Monitoring.
Dependency-Pinning mit Lock-Files konsequent durchsetzen. package-lock.json oder pnpm-lock.yaml gehören versioniert ins Repository. Jede Abweichung in CI sollte den Build abbrechen, nicht stillschweigend akzeptiert werden.
Fazit
Der Trivy-Angriff zeigt ein strukturelles Problem: Die Tools, denen Teams ihre Security anvertrauen, sind selbst Teil der Angriffsfläche. Blindes Vertrauen in Drittanbieter-Actions und Paketquellen reicht nicht mehr. SHA-Pinning, Postinstall-Isolation und aktives Monitoring der eigenen Supply Chain sind keine optionalen Best Practices mehr, sondern Grundvoraussetzungen für sicheres Deployment.
Wer seine CI/CD-Pipelines auf Supply-Chain-Resilienz prüfen lassen möchte oder Unterstützung beim Aufbau sicherer Deployment-Prozesse braucht, findet bei EverBright IT praktische Erfahrung aus Enterprise-Projekten im DACH-Raum.
Häufige Fragen
Was ist SHA-Pinning und warum ist es wichtig?
SHA-Pinning bindet GitHub Actions an einen spezifischen Commit-Hash statt an einen Tag. Tags wie @v1 sind bewegliche Ziele, ein Force-Push ändert, worauf sie zeigen. Commit-SHAs sind kryptografisch an einen Commit gebunden, lassen sich auch mit vollem Repository-Zugriff nicht austauschen. Das eliminiert die Angriffsfläche von Tag-Poisoning.
Wie funktioniert die CanisterWorm-Propagation?
Der Wurm nutzte gestohlene npm-Tokens, um 141+ schadhafte Artefakte über 66 Pakete zu infizieren. Er polte alle 50 Minuten einen Internet Computer Protocol (ICP) Canister nach neuen Payloads. Das Perfide: Der Wurm propagierte sich selbst weiter, erntete npm-Tokens aus Entwicklerumgebungen und infizierte jedes erreichbare Paket automatisch.
Was sollten Teams sofort tun, falls sie Trivy verwendet haben?
Alle fünf CVEs haben Patches, spielen Sie diese ein. CVE-2026-24763 und CVE-2026-30741 sind kritisch genug, um ungepatchte Instanzen sofort vom Netz zu nehmen. Rotieren Sie Secrets: API-Keys, Deployment-Tokens, SSH-Keys, Cloud-Credentials. Prüfen Sie CI/CD-Runner auf verdächtige systemd-Services, ICP-Netzwerkverbindungen und /proc-Zugriffe.
Wie verhindert man Supply-Chain-Angriffe grundsätzlich?
Dependency-Pinning mit versionierten Lock-Files (package-lock.json, pnpm-lock.yaml) ist essenziell. npm install —ignore-scripts sollte Standard sein, kombiniert mit einer Allowlist für Pakete, die Build-Skripte brauchen. Postinstall-Hooks blockieren den primären Infektionsvektor. Runtime-Monitoring und regelmäßige Dependency-Audits gehören zur Routine.
