Trivy Supply Chain Attack (March 2026): How a Security Scanner Got Hacked

On March 19, 2026, the tool that thousands of organizations use to find vulnerabilities became the vulnerability.

Aqua Security’s Trivy — one of the most widely deployed open-source vulnerability scanners, integrated into CI/CD pipelines across every major cloud platform — was compromized by a threat group identifying as TeamPCP. The attackers used credentials retained from an earlier, incompletely remediated breach to force-push malicious code to 76 of 77 version tags in the trivy-action GitHub Action, publish backdoored binaries as Trivy v0.69.4, and distribute compromised Docker images (v0.69.5, v0.69.6) to Docker Hub. The malicious payload harvested CI/CD secrets, cloud credentials, SSH keys, and Docker configurations from every system that ran the compromised scanner.

The legitimate Trivy scan still ran afterward. The output looked normal. Many users would have seen green checks in their pipeline and moved on, unaware that their secrets had been exfiltrated to attacker-controlled infrastructure. TeamPCP subsequently expanded the campaign to npm (via a self-propagating worm called CanisterWorm), VS Code extensions on Open VSX, Checkmarx’s KICS GitHub Actions, and LiteLLM on PyPI.

 

Why This Matters Beyond Trivy

The Trivy incident is a lesson about how the security toolchain itself can become an attack surface. Security scanners run with elevated privileges by design — they need access to source code, container images, build artifacts, and often CI/CD secrets to function. 

When a scanner is compromised, the attacker inherits the privileges. The blast radius is everything the scanner can reach. And in most pipeline configurations, that means everything.

The deeper problem is operational trust. Organizations pin GitHub Action versions, pull Docker images by tag, and assume that a verified publisher’s release is safe. 

The Trivy attack exploited one of those assumptions. 

As Docker’s post-incident analysis noted: mutable tags are not a security boundary, digest pinning alone does not verify provenance, and supply chain integrity requires more than scanning.

 

What Would Have Actually Caught This

The Trivy attack had no CVE. The malicious code was injected through compromised credentials and published as a legitimate-looking release. A conventional vulnerability scanner — including Trivy itself — would have returned zero findings, because the database had nothing to match against.

But the attack left signals that were visible in hindsight and should have been visible in real time. The Docker Hub images v0.69.5 and v0.69.6 were published without corresponding GitHub releases or tags — a mismatch between distribution channels that, in any auditable release process, should trigger an alert. The malicious binary called out to scan.aquasecurtiy.org, a typosquatted domain one transposition away from aquasecurity.org — the kind of infrastructure red flag that network monitoring or sandbox analysis would catch. The service account that triggered the release had been dormant for weeks before suddenly publishing three versions in rapid succession.

None of these signals live in a CVE database. They live in release metadata, network behavior, and publish-pattern anomalies — layers of verification that most organizations never implement around the tools they trust the most. The Trivy incident made one thing painfully clear: if the only security check on your scanner is "is this version number the one I expected," you have no security check at all. Digest pinning, provenance attestation, and distribution-channel consistency checks are the minimum — and they need to apply to your security tools with the same rigor you apply to your production dependencies.

 

Practical Takeaways

Pin by digest, not by tag

Image tags are mutable pointers. The Trivy attack worked because tags were silently repointed to malicious content. Pin to sha256 digests in CI/CD.

Verify provenance

A pinned digest guarantees the same bytes; it does not guarantee those bytes came from a trusted build. Verify signed attestations where available.

Assume security tools are the attack surface

Any tool that runs in your pipeline with access to secrets is a high-value target. Apply the same supply chain scrutiny to your scanners that you apply to your dependencies.

Run SCS

CVE-matching misses attacks like Trivy’s entirely. Package reputation, provenance verification, and behavioral analysis are what catch supply chain manipulation before it reaches your pipeline.

 

The irony of a vulnerability scanner being weaponized is hard to miss. But the lesson is priceless: blind trust in any single tool, vendor, or distribution channel is itself a security risk. The organizations that weathered the Trivy incident best were the ones that had layered controls — digest pinning, provenance checks, and SCA with supply chain-specific detection.