On March 19, Trivy—one of the most trusted security scanners in CI/CD pipelines—was compromised for the second time in 30 days. Thousands of organizations unknowingly ran malware in their deployment workflows, exposing AWS credentials, Kubernetes secrets, and SSH keys to the TeamPCP cybercriminal group. The tool designed to find vulnerabilities became the vulnerability itself.
The Attack: 75 GitHub Action Tags Hijacked
Attackers force-pushed 75 malicious version tags in the trivy-action repository at 17:43 UTC on March 19. Organizations pinning GitHub Actions to version tags (like @v0.35.0) unknowingly pulled credential-stealing malware instead of legitimate security scans. The malware dumped CI/CD runner memory, extracted environment variables containing cloud credentials, encrypted everything with AES-256 and RSA-4096, and exfiltrated data to a typosquatted domain: scan.aquasecurtiy[.]org. Notice the typo—”tiy” instead of “ty.”
Moreover, the attackers built in a fallback mechanism. If exfiltration failed, the malware abused captured GitHub Personal Access Tokens to create repositories named “tpcp-docs” in victim accounts, staging stolen credentials publicly on GitHub itself. That’s both sophisticated and brazen—using your own infrastructure against you.
Consequently, version tag pinning is fundamentally insecure. Tags can be rewritten with force-pushes; commit SHAs cannot. Organizations trusting version tags learned this the hard way.
Second Trivy Breach Shows Incomplete Incident Response
Here’s what makes this unacceptable: Trivy was first compromised on February 20-28 by “hackerbot-claw,” an AI bot that exploited a vulnerable pull_request_target workflow. Aqua Security responded by removing the vulnerable workflow file and rotating credentials. They released v0.69.2 and claimed the issue was resolved.
However, the March 19 attack revealed those credentials weren’t fully rotated. Attackers retained access to the aqua-bot service account and returned three weeks later. Aqua Security admitted credential rotation “wasn’t atomic”—security speak for “we messed up.” Socket and Wiz security researchers traced the root cause to incomplete containment of the first breach.
One breach is unfortunate. Two in 30 days suggests incompetence. Incomplete credential rotation after a security incident is a fundamental failure. If Aqua Security can’t secure their own flagship security tool, why should organizations trust them to protect production systems?
What Developers Must Do Now
If you’re running trivy-action pinned to version tags, assume you’re compromised. Any organization using Trivy between March 19-21 may have exposed credentials without realizing it.
Immediate Actions
- Rotate ALL secrets: AWS, GCP, Azure, Kubernetes, SSH keys, Docker Hub credentials
- Pin to safe versions: trivy v0.69.3, trivy-action @0.35.0, or commit SHA @57a97c7e7821a5776cebc9bb87c984fa69cba8f1
- Search your GitHub organizations for repositories named “tpcp-docs”—that’s the exfiltration fallback
- Block outbound connections to 45.148.10[.]212 and scan.aquasecurtiy[.]org at your network perimeter
Long-Term Fixes
- Switch ALL GitHub Actions from version tag pinning to commit SHA pinning. Tags are mutable; SHAs are immutable.
- Implement automated credential rotation schedules—no manual, partial rotations
- Monitor for unauthorized force-pushes in critical repositories
Furthermore, Hacker News developers are already asking for “Trivy alternatives while Aqua rebuilds their reputation.” Grype (Anchore) and Clair are free, open-source vulnerability scanners without recent breaches. Both offer comparable vulnerability detection with different trade-offs.
The CI/CD Security Tool Paradox
Organizations adopt security scanners like Trivy to reduce risk, but these tools run with elevated privileges in CI/CD pipelines. They access AWS credentials, Kubernetes secrets, SSH keys, Docker Hub tokens—everything needed to deploy and operate infrastructure. That makes them extraordinarily high-value targets.
Trivy has 32,000 GitHub stars. Compromising one widely-adopted security tool provides attackers access to thousands of downstream victims simultaneously. TeamPCP understood this. They didn’t target random software—they deliberately attacked a security scanner.
The irony cuts deep. We trust security tools implicitly, granting them permissions we’d never give to application code. We assume scanners are secure because they’re designed to find vulnerabilities. However, that assumption is dangerous. Security tools are software, maintained by humans, running on infrastructure that can be compromised.
If we can’t trust security tools, what can we trust? The answer is uncomfortable: nothing, by default. Apply zero-trust principles to your security tooling. Pin to immutable identifiers. Monitor for anomalous behavior. Rotate credentials aggressively. Audit your supply chain, including the tools meant to secure it.
Aqua Security must rebuild credibility, but this incident exposes a broader problem. The DevSecOps model of “add security scanning to your pipeline” is flawed if we don’t treat scanners themselves as potential attack vectors. Two breaches in 30 days prove that trust is fragile—and misplaced trust is liability.
