🚨 Trivy has been hacked, again.

---

What happened?

Attackers compromised the official aquasecurity/trivy-action GitHub Action — the one people use to run Trivy vulnerability scans in CI/CD pipelines. This was disclosed today (March 20, 2026). It's the *second* Trivy-related supply chain attack this month — the first one hit the Trivy VS Code extension on OpenVSX, where injected code tried to abuse local AI coding agents.

How did they do it?

The attacker force-pushed 75 out of 76 version tags in the aquasecurity/trivy-action repository. So if your workflow references this action by a version tag like @0.34.2, @0.33.0, or @0.18.0 — you're running malicious code. The only tag that wasn't touched is @0.35.0.

The tricky part: the malicious code runs *before* the real Trivy scan starts, so everything looks normal to the user.

What does the malware actually do?

It dumps the runner's process memory to grab secrets, harvests SSH keys, and steals credentials for AWS, GCP, Azure, and also Kubernetes service account tokens. Basically, it's an infostealer designed specifically for CI/CD environments.

How big is the blast radius?

Over 10,000 workflow files on GitHub reference this action, so potentially a lot of projects are affected. The compromised tags were still active at the time the article was written.

Key risks for you to think about:

Given your EKS and GitOps setup, here are the things I'd pay attention to:

1. K8s service account tokens leaked — if any of your CI pipelines use trivy-action and have access to your EKS clusters, those tokens could be compromised. Rotate them.

2. AWS credentials exposed — your IRSA roles, Secrets Manager access, anything the GitHub runner had in its environment could be stolen.

3. Tag pinning is not enough — this attack shows that even pinning to a specific version tag like @0.33.0 doesn't protect you. Tags in Git can be force-pushed. The safe approach is to pin to a full commit SHA not a tag.

4. Second attack in one month on the same tool — Trivy is popular, and attackers clearly see it as a high-value target. Worth thinking about whether your security scanning toolchain has a single point of failure.

What to do right now:

- Check if any of your GitHub Actions workflows reference aquasecurity/trivy-action by tag (not by SHA).
- If yes, treat your CI/CD secrets as compromised — rotate AWS keys, SSH keys, K8s tokens.
- Switch to referencing actions by commit SHA instead of version tag.
- Review your GitHub Actions workflow permissions — make sure you use least-privilege permissions: blocks.

This is a really good example of why "shift left security" needs to also include securing the security tools themselves. The scanner became the attack vector.

https://socket.dev/blog/trivy-under-attack-again-github-actions-compromise