On March 19, 2026, a threat actor published malicious releases of Trivy, the most widely used open-source container vulnerability scanner. 76 of its 77 release tags were poisoned with credential-stealing malware. The attack has since spread to Docker Hub images and downstream npm packages. Mandiant estimates up to 10,000 organizations may be affected.
If your CI/CD pipeline uses trivy-action, setup-trivy, or pulls the Trivy container image, you need to act now.
What happened
This was a multi-stage supply chain attack by TeamPCP (also tracked as DeadCatx3 / PCPcat), a threat group that targets cloud-native infrastructure.
Late February 2026. Attackers exploited a misconfiguration in Trivy's GitHub Actions environment and extracted a privileged access token. That gave them access to the project's release automation.
March 1. The Trivy team disclosed the breach and rotated credentials. The rotation missed some tokens, and the attackers kept access.
March 19. The attackers published a malicious Trivy v0.69.4 release and force-pushed 76 of 77 version tags in aquasecurity/trivy-action to credential-stealing payloads. All 7 tags in aquasecurity/setup-trivy were replaced too.
March 22. All 44 repositories in Aqua Security's GitHub organization were defaced at once, confirming how deep the compromise went.
The attack is still expanding. Compromised Docker Hub images have been found, and a self-propagating worm called CanisterWorm is spreading through stolen npm credentials.
Who is affected
You're potentially affected if your CI/CD pipelines reference any of these:
aquasecurity/trivy-action(GitHub Action)aquasecurity/setup-trivy(GitHub Action)aquasec/trivyDocker image (tags pulled after late February 2026)- Trivy v0.69.4 binary
The payload goes after secrets in CI/CD environments: AWS/GCP/Azure credentials, SSH keys, Kubernetes tokens, Docker configs, Git credentials, and API tokens.
How to check if you're affected
1. Audit your GitHub Actions workflows
Search your repositories for Trivy references:
grep -r "aquasecurity/trivy-action\|aquasecurity/setup-trivy" .github/workflows/
If you reference these actions by tag (e.g., @v1, @v2), you are at risk. Tags are mutable. The attacker moved them to point at malicious commits.
If you pinned to a full commit SHA (e.g., @a1b2c3d4...), you're likely safe, assuming the SHA predates late February 2026.
2. Check your CI/CD logs
Look for unexpected network connections or secret access in your GitHub Actions run logs from the past month. The payload tried to exfiltrate secrets to external endpoints.
3. Review Docker image pulls
If you pull the aquasec/trivy image in CI or production, verify the image digest against the Trivy security advisory.
What to do right now
Immediate actions:
Pin GitHub Actions to commit SHAs, not tags. This is the most important takeaway. Replace
uses: aquasecurity/trivy-action@v1with the full SHA of a known-good commit.Rotate any secrets that were accessible to your CI/CD pipelines during the affected period (late February through now). Cloud provider credentials, Docker Hub tokens, npm tokens, SSH keys, Kubernetes service account tokens. All of them.
Audit downstream artifacts. If your CI pipeline ran the compromised action, any images it built, packages it published, or deployments it triggered should be treated as compromised until proven otherwise.
Check for CanisterWorm. If your pipeline publishes npm packages, verify that no unauthorized versions were published using stolen credentials.
Longer-term hardening:
- Treat CI/CD runners like production infrastructure. Same monitoring, same secret management, same least-privilege principles.
- Use short-lived credentials. OIDC federation for cloud providers, short-lived tokens for registries. Stop putting long-lived secrets in CI.
- Enable GitHub's required workflow approvals for third-party action updates.
- Monitor your dependency supply chain. Tools like StepSecurity Harden-Runner can detect anomalous network activity in GitHub Actions.
The bigger picture
A security scanner, the tool organizations trust to find vulnerabilities, became the attack vector. Security tools have the same attack surface as any other software, but they tend to run with elevated privileges and broad access to credentials.
Supply chain security isn't just about your application dependencies. It's about every tool in your pipeline: scanners, linters, deployment automation. Every one of them is a potential entry point.
The real question is whether your architecture limits the blast radius when one of these tools gets popped. If stolen CI credentials can reach your production Kubernetes clusters, do you know which workloads, secrets, and services are in the blast radius? That's the kind of visibility that matters after an incident like this.
It's what we built Juliet to answer.
Questions about this post or need help assessing your exposure? Reach us at contact@juliet.sh.