The compromise of Aqua Security’s Trivy on 19 March 2026 was not just another vulnerability disclosure. It was a wake-up call for every development team that trusts its toolchain. When one of the most widely used open-source security scanners becomes the attack vector, the rules change.
Here is what happened, why it matters for your projects, and what your team should do about it right now.
TL;DR
- Trivy, a popular open-source vulnerability scanner, was compromised on 19 March 2026 in a multi-phase supply chain attack
- Attackers stole CI/CD credentials, poisoned 75 GitHub Actions tags, deployed persistent backdoors, and launched a self-propagating npm worm (CanisterWorm)
- The attack exploited trust in security tooling itself, turning scanners and CI pipelines into credential-harvesting infrastructure
- Development teams need to pin dependencies by hash, audit CI/CD secrets regularly, and treat security tools with the same zero-trust approach as any other third-party code
- This is part of a broader trend: supply chain attacks are shifting from targeting application dependencies to targeting developer infrastructure
What Happened
The attack unfolded in five phases, each building on the last. Understanding the chain matters because it reveals how a single compromised credential can cascade across an entire ecosystem.
Phase 1: Credential reuse. Three weeks before the main attack, an automated bot exploited a misconfigured GitHub Actions workflow to steal a Personal Access Token. Aqua Security discovered this and rotated credentials, but the rotation was incomplete. The attackers retained access to surviving tokens.
Phase 2: Repository takeover. Using those credentials, the group (tracked as TeamPCP) compromised a service account and pushed a malicious release tag. This triggered automated pipelines that distributed backdoored binaries to GitHub Releases, Docker Hub, GHCR, and Amazon ECR. If your CI pulled Trivy during this window, you may have run compromised code.
Phase 3: GitHub Actions tag poisoning. The attackers force-pushed 75 out of 76 version tags in the trivy-action repository. Any workflow referencing a version tag like @v0.28.0 silently ran attacker-controlled code. The commits reused original author metadata and timestamps, making the tampering nearly invisible in Git history.
Phase 4: Credential harvesting at scale. The poisoned actions read directly from GitHub Actions Runner memory, bypassing log masking. They harvested SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, Docker registry credentials, database passwords, and TLS private keys. Stolen data was encrypted and exfiltrated to a typosquatted domain, with a fallback that used victims’ own GitHub tokens to stage data in public repositories.
Phase 5: Self-propagating worm. Using stolen npm tokens, TeamPCP launched CanisterWorm, which compromised 47+ npm packages across multiple scopes. Each infected package stole tokens from its installer and used them to publish further malicious versions, creating a self-propagating chain. The latest count exceeds 141 affected packages.
Why This Is Different
Supply chain attacks are not new. The SolarWinds breach in 2020, the event-stream incident in 2018, the xz utils backdoor in 2024 — each demonstrated different aspects of the problem. But the Trivy attack represents something qualitatively different.
The security scanner was the weapon. Teams install Trivy specifically to check for vulnerabilities. It runs with elevated permissions, has access to source code and credentials, and is deeply embedded in CI/CD pipelines. Compromising a security tool gives attackers a level of access that compromising a utility library never could.
The attack was self-amplifying. Unlike traditional supply chain attacks that compromise a single package and wait for installations, CanisterWorm actively propagated. Each victim became an unwitting distributor. This turns a linear attack into an exponential one.
Trust relationships were weaponised at every layer. GitHub Actions trust version tags. Docker Hub trusts automated builds. npm trusts published packages from authenticated accounts. The attackers did not break any of these trust mechanisms — they operated within them, using legitimate credentials at every step.
What Your Team Should Do
The practical response breaks into immediate actions and longer-term changes to how you manage your toolchain.
Immediate (this week)
Check if you were exposed. If your CI/CD pipelines used Trivy or trivy-action between 14 and 22 March, assume credentials may have been compromised. Rotate all secrets that were accessible to those pipelines — cloud provider keys, Docker registry tokens, database passwords, SSH keys. Yes, all of them.
Pin your GitHub Actions by commit hash, not version tag. Instead of uses: aquasecurity/[email protected], use the full SHA: uses: aquasecurity/trivy-action@abc123def456.... Version tags are mutable references that can be pointed anywhere. Commit hashes cannot be changed without detection.
Audit your npm lockfiles. Run npm audit and check for any packages flagged in the CanisterWorm advisory. Review your package-lock.json for unexpected version bumps in the affected scope.
Longer term
Treat security tools as attack surface. Your vulnerability scanner, your SAST tool, your dependency checker — these all run with significant privileges. Apply the same scrutiny to their updates that you would to a database migration or infrastructure change. Pin versions. Review changelogs. Verify signatures.
Implement least-privilege CI/CD secrets. If your GitHub Actions workflow only needs to push to a container registry, it should not have access to your AWS root credentials. Scope secrets to exactly what each job needs, and use short-lived tokens where possible.
Monitor for anomalous publishing activity. If you maintain npm packages, set up alerts for unexpected publishes. Tools like Socket.dev can flag suspicious package behaviour — new postinstall scripts, unexpected network calls, obfuscated code.
Use multiple layers of verification. Sigstore and cosign let you verify that container images and binaries were built by the expected pipeline. SLSA provenance attestations provide a verifiable build record. Neither would have prevented every phase of this attack, but they raise the bar significantly.
The Broader Trend
The Trivy attack sits within a clear pattern. Attackers are shifting upstream — from targeting application code to targeting the tools and pipelines that build, test, and deploy that code. The reasons are obvious: compromise a popular tool and you compromise thousands of projects simultaneously.
This is particularly relevant for teams using AI coding agents, which introduce additional trust relationships into the development process. When an AI agent suggests a dependency, installs a package, or configures a pipeline, it is making trust decisions on your behalf. The same principles apply: verify, pin, audit.
For smaller teams that cannot dedicate full-time security engineers to supply chain monitoring, the practical approach is defence in depth. No single measure prevents attacks like this. But pinning dependencies by hash, scoping CI/CD secrets, monitoring for anomalous behaviour, and maintaining a rapid credential rotation capability together make a meaningful difference.
The lesson from Trivy is not that open-source security tools are unreliable. The project responded quickly, the community mobilised, and the attack was contained. The lesson is that trust must be verified continuously, even — especially — for the tools you trust most.
Building CI/CD pipelines that need to withstand modern supply chain threats? REPTILEHAUS helps teams implement secure DevOps practices from the ground up. Get in touch to discuss your security posture.
📷 Photo by Steve Barker on Unsplash
