Der weit verbreitete Open-Source-Schwachstellenscanner Trivy ist Ziel einer komplexen Supply-Chain-Attacke geworden. Angreifer schleusten einen Infostealer in GitHub Actions und Releases des Projekts ein und konnten so sensible Geheimnisse aus CI/CD-Pipelines und von Entwicklerrechnern abgreifen. Der Vorfall zeigt, wie riskant selbst vertrauenswürdige Security-Werkzeuge in der Software-Lieferkette sein können.
Trivy im DevSecOps-Umfeld und Bedeutung des Vorfalls
Trivy wird von Aqua Security entwickelt und zählt mit über 33.200 GitHub-Sternen zu den populärsten Open-Source-Vulnerability-Scannern. Das Tool ist tief in DevSecOps-Workflows, Container-Builds, Kubernetes-Cluster-Scans und Repositorien-Prüfungen integriert. Eine Kompromittierung seiner Lieferkette wirkt daher unmittelbar auf die Sicherheit zahlreicher Unternehmen, die Trivy automatisiert in ihren Pipelines einsetzen.
Die Angreifer nutzten gestohlene Zugangsdaten, um im Repository aquasecurity/trivy-action einen force-push für 75 von 76 Tags durchzuführen und zusätzlich sieben setup-trivy-Tags zu ersetzen. Betroffen waren unter anderem die Versionen @0.34.2, @0.33 und @0.18.0, während @0.35.0 unverändert blieb. Ein trojanisiertes Release Trivy v0.69.4 war rund drei Stunden verfügbar, die manipulierten GitHub-Actions-Tags etwa zwölf Stunden – genug Zeit, um automatisierte Workflows weltweit zu infizieren.
Angriffsweg: umgebogene Tags und trojanisierte Builds
Analysen von Sicherheitsanbietern wie Socket und Wiz zeigen, dass die Angreifer keine neuen Releases erzeugten, sondern bestehende Tags auf manipulierte Commits umleiteten. Sie kopierten Metadaten wie Autor, E-Mail, Zeitstempel und Commit-Messages inklusive PR-Nummern. Dadurch blieb die Commit-Historie auf den ersten Blick unauffällig und klassische Alarmmechanismen sprangen seltener an.
Parallel passten die Täter das Skript entrypoint.sh der GitHub Action an und veröffentlichten trojanisierte Trivy-Binaries über GitHub Releases, Docker Hub, GHCR und ECR. Jeder CI/CD-Workflow, der sich in dieser Zeit auf die kompromittierten Tags bezog, lud automatisch den Schadcode. Es handelt sich damit um einen typischen Supply-Chain-Angriff, bei dem ein vertrauenswürdiger Baustein zum Einfallstor in zahlreiche fremde Umgebungen wird.
Infostealer in CI/CD-Pipelines und auf Entwicklerrechnern
Der Schadcode startete weiterhin den legitimen Trivy-Scan, um das gewohnte Verhalten nicht zu stören, und führte parallel einen Infostealer aus. Ziel war die systematische Sammlung sensibler Informationen aus Build-Umgebungen und Entwickler-Workstations.
Abgegriffen wurden unter anderem Umgebungsvariablen, SSH-Schlüssel, Cloud-Credentials für AWS, GCP und Azure, kubeconfig-Dateien, Docker-Konfigurationen, .env-Files, Datenbankpasswörter, Slack- und Discord-Tokens, TLS-Schlüssel, VPN-Profile sowie Kryptowallet-Daten. Zusätzlich wurden Netzwerkschnittstellen aufgelistet und Speicherbereiche des Prozesses GitHub Actions Runner.Worker nach JSON-Strukturen mit Geheimnissen durchsucht.
Die gesammelten Daten wurden verschlüsselt und per POST-Request an die typosquattende Domain scan.aquasecurtiy[.]org exfiltriert, die der legitimen Domain von Aqua Security stark ähnelt. Scheiterte dieser Kanal, legte die Malware im GitHub-Account des Opfers ein öffentliches Repository „tpcp-docs“ an und lud die Informationen dort hoch – ein ungewöhnlicher, aber effektiver Ausweichkanal.
Auf Entwicklerrechnern installierte der trojanisierte Trivy-Binary zusätzlich ein Python-Skript (~/.config/systemd/user/sysmon.py) als systemd-Service und kontaktierte regelmässig einen Command-and-Control-Server, um weitere Payloads nachzuladen. Damit erreichten die Angreifer eine persistente Verankerung im System.
TeamPCP als mutmassliche Angreifer und Einordnung in die Threat-Landschaft
Indizien wie der Kommentar „TeamPCP Cloud stealer“ in einem Python-Skript lassen auf die Gruppe TeamPCP (auch DeadCatx3, PCPcat, ShellForce) schliessen. Laut den vorliegenden Analysen konzentriert sich diese Gruppe auf Cloud-Angriffe und missbraucht häufig falsch konfigurierte Docker-APIs, Kubernetes-Cluster, Ray-Dashboards und Redis-Server.
Der Sicherheitsanbieter Aikido sieht zudem Verbindungen zur Kampagne CanisterWorm, einem selbstreplizierenden Wurm, der npm-Pakete über gestohlene Tokens mit Backdoors versieht. Gemeinsam mit bekannten Vorfällen wie SolarWinds, Codecov-Upload-Skripten und bösartigen npm-Paketen unterstreicht der Angriff den Trend, dass Bedrohungsakteure ihre Aktivitäten immer stärker „nach links verschieben“ – also direkt in Entwicklungs- und Build-Prozesse hinein.
Root Cause: kompromittierte VS-Code-Erweiterung und fehlende vollständige Bereinigung
Nach Angaben des Trivy-Maintainers Itai Shakury geht der aktuelle Vorfall auf eine frühere Attacke vom 1. März 2026 zurück. Damals wurde die Aqua-Trivy-Erweiterung für VS Code kompromittiert. Darüber erlangten Angreifer Zugangsdaten mit Schreibrechten auf den GitHub-Account des Projekts.
Im Anschluss wurden zwar Tokens ausgetauscht, doch blieben offenbar weitere Artefakte wie API-Schlüssel, Zertifikate und Passwörter im Besitz der Angreifer. Diese Restexponierung ermöglichte den späteren, deutlich umfangreicheren Angriff. Brisant ist zudem, dass Spuren der Kompromittierung von März aus dem Trivy-Repository entfernt wurden, was die forensische Aufarbeitung zusätzlich erschwerte.
Risiken für Unternehmen und empfohlene Sicherheitsmassnahmen
Wer ist betroffen?
Organisationen, die die kompromittierten Trivy-GitHub-Actions oder Binaries eingesetzt haben, sollten von einer vollständigen Kompromittierung ihrer Geheimnisse ausgehen. Dies betrifft nicht nur Pipeline-Variablen, sondern sämtliche angebundenen Ressourcen: Cloud-Konten, Repositorien, Kubernetes-Cluster, Datenbanken und Messaging-Dienste.
Sofortmassnahmen für CI/CD- und DevSecOps-Teams
Als unmittelbare Reaktion ist eine umfassende Rotation aller Secrets erforderlich: Cloud-Zugänge, SSH-Schlüssel, API-Tokens, Datenbankpasswörter, OAuth-Tokens, VPN-Schlüssel und Zugangsdaten zu Messenger- und Collaboration-Diensten. Zusätzlich sollten Unternehmen:
- alle CI/CD-Pipelines und GitHub-Actions-Logs auf verdächtige Ausführungen und ungewöhnliche ausgehende Verbindungen prüfen;
- statt unveränderlicher Tags feste Commit-Hashes in GitHub Actions referenzieren;
- GitHub-Tokens strikt nach dem Least-Privilege-Prinzip beschränken und Hardware-Keys/2FA für kritische Accounts erzwingen;
- regelmässiges Secret Scanning sowie Signierung und Verifikationsprüfungen für Releases etablieren;
- den Umgang mit IDE-Erweiterungen, Plugins und Dritttools mit Zugriff auf Entwickler-Credentials organisatorisch und technisch härten.
Die Trivy-Attacke macht deutlich, dass die Sicherheit moderner Software-Lieferketten nicht allein von Codequalität abhängt, sondern von reifen Prozessen für Zugriffs- und Geheimnisverwaltung, Release-Integrität und Tool-Governance. Unternehmen sollten Sicherheitswerkzeuge in CI/CD als Komponenten mit erhöhtem Risiko betrachten, deren Herkunft, Versionierung (idealerweise per Commit-Hash) und Verhalten kontinuierlich überwacht werden. Wer seine Teams in sicheren Entwicklungs- und Betriebspraktiken schult und Supply-Chain-Schutz als strategische Aufgabe begreift, reduziert die Angriffsfläche künftiger Kampagnen erheblich.
