Trivy GitHub Actions compromised again as attackers hijack 75 tags to steal CI/CD secrets

Trivy has suffered a second supply chain incident in March, this time through its GitHub Actions ecosystem. Security researchers say an attacker force-pushed 75 out of 76 version tags in aquasecurity/trivy-action, causing workflows pinned to version tags to pull malicious code that steals secrets from CI/CD runners.

The compromise did not stop with one repo. Researchers also found that aquasecurity/setup-trivy was compromised, and only v0.2.6 appears to be clean after incident response. For the Trivy scanner itself, the malicious v0.69.4 release was removed, and Homebrew rolled back to v0.69.3.

This is serious because GitHub Actions tags look stable, but they are not truly immutable. Once an attacker rewrites a tag, any workflow that references that tag can silently begin executing malicious code without any change in the workflow file. Socket says more than 10,000 GitHub workflow files reference the affected Trivy action, which gives this incident a potentially wide blast radius.

What happened in the Trivy GitHub Actions breach

Socket says the attacker used valid credentials with write access and force-updated 75 existing tags in aquasecurity/trivy-action. The action still ran the legitimate Trivy scan, but only after the malicious payload executed first, which made the compromise harder to spot in normal CI output.

Socket also says the attack did not require a GitHub platform exploit. The attacker appears to have used compromised credentials left over from the earlier March breach involving Trivy’s ecosystem, then used that access to rewrite tags directly.

StepSecurity separately documented the same second incident and confirmed that the rogue v0.69.4 Trivy release was removed, while setup-trivy tags were deleted during response efforts and replaced with a clean v0.2.6 release.

Why this attack is more dangerous than it looks

The delivery method matters as much as the malware. GitHub resolves an action tag like aquasecurity/[email protected] to whatever commit that tag points to at runtime. If the tag moves, the workflow follows it automatically. That means teams that thought they had pinned a stable version were still exposed.

Socket says the malicious payload targeted runner process memory, environment variables, SSH keys, cloud credentials, Kubernetes service account tokens, Git and Docker configs, and other secrets commonly found in build pipelines. StepSecurity’s analysis of the broader Trivy incident also showed malicious activity tied to credential theft and follow-on compromise.

What the malware tried to steal

Target	Why it matters
Environment variables	Often contain API keys, tokens, and secrets
SSH keys	Can open access to source repos and servers
Cloud credentials	Can expose AWS, GCP, and Azure environments
Kubernetes tokens	Can expose clusters and workloads
Git and Docker configs	Can reveal registry and source control access
Wallet and crypto-related files	Can expose financial assets

These behaviors come from Socket’s incident write-up and the sample text you shared.

Safe versions and what users should move to

Researchers and maintainers have pointed users toward clean versions after the compromise. Based on the incident reporting and rollback activity, the currently safe references are:

• trivy v0.69.3
• trivy-action v0.35.0
• setup-trivy v0.2.6

Socket says v0.35.0 appears to be the only unaffected tag in trivy-action. StepSecurity says setup-trivy only retained v0.2.6 as a clean tag, and Homebrew rolled Trivy back to v0.69.3.

Safe versions at a glance

Component	Safe version
trivy	0.69.3
trivy-action	0.35.0
setup-trivy	0.2.6

Why pinning to tags failed

GitHub has long recommended pinning actions to full commit SHAs rather than version tags. Socket’s analysis shows exactly why. The attacker rewrote tags to malicious commits while preserving metadata that made the changes look legitimate at first glance.

That is the key lesson from this attack. A version tag feels stable, but it is only a movable pointer. A full commit SHA gives a much stronger integrity guarantee. This is not a theoretical risk anymore. The Trivy incident shows how easily tag trust can collapse once a repo credential is compromised.

What teams should do right now

Anyone who used Trivy in GitHub Actions during the affected window should assume CI/CD secrets may have been exposed. Aqua’s earlier incident discussion shows the project was already dealing with a March compromise involving stolen credentials, and Socket says the second wave likely grew from incomplete containment of that earlier breach.

Immediate response steps

• Rotate all CI/CD secrets, tokens, SSH keys, and cloud credentials
• Replace tag-based GitHub Action references with full commit SHAs
• Move to trivy 0.69.3, trivy-action 0.35.0, and setup-trivy 0.2.6
• Check for outbound traffic or logs tied to the attacker infrastructure described by researchers
• Review GitHub accounts and repos for suspicious activity, especially fallback exfiltration behavior
• Audit past workflow runs that used affected Trivy actions

FAQ