How Attackers Infiltrated One of Open Source's Most Trusted Security Tools

Trivy, developed by Aqua Security, sits at the heart of countless CI/CD pipelines. With over 32,000 GitHub stars and more than 100 million Docker Hub downloads, it's one of the most widely adopted open-source vulnerability scanners in existence. Developers rely on it daily to detect vulnerabilities and exposed secrets inside container images and pipeline workflows. That trust is exactly what made it such an attractive target.

Attackers compromised three separate components of the Trivy project simultaneously: trivy-action (the official GitHub Action for running Trivy scans), setup-trivy (a helper action for installing the scanner), and the Trivy binary itself. Backdoored artifacts were then published across GitHub releases, Docker Hub, the GitHub Container Registry, and the Amazon Elastic Container Registry — essentially every major distribution channel the project uses.

According to security firm Socket, 75 of 76 version tags in trivy-action were overwritten with malicious code, along with seven tags in setup-trivy. The only unaffected trivy-action tag was version 0.35.0. Widely used versions — including 0.34.2, 0.33.0, and 0.18.0 — were among those compromised.

What the Malware Actually Does Inside Your Pipeline

When the malicious binary executes, it doesn't just run the attack — it also runs the legitimate Trivy service in parallel. That's deliberate. Keeping normal operations running reduces the chance that anything looks wrong to the developer or the pipeline logs.

On GitHub Actions runners, the embedded credential stealer reads process memory to extract secrets, then searches the filesystem for SSH keys, cloud provider credentials, Kubernetes tokens, Docker registry configurations, and cryptocurrency wallets. The stolen data gets encrypted and sent to a typosquatted domain mimicking Aqua Security's legitimate site.

And if that fails? The malware has a fallback. It creates a public GitHub repository named "tpcp-docs" on the victim's own account and uploads the encrypted stolen data there. It's a clever and deeply unsettling move — using the victim's own infrastructure against them.

Beyond the immediate credential theft, the attack also installs a persistent Python dropper on developer machines. That dropper connects to an attacker-controlled server every five minutes, polling for additional payloads to execute. This isn't a smash-and-grab — it's designed for persistence.

The Tag Manipulation Technique That Made It Nearly Invisible

Here's where the technical sophistication really shows. Instead of creating new releases — which would trigger notifications to watchers — the attackers force-pushed existing version tags to point to new malicious commits. Git tags are just pointers to specific commits. By silently redirecting where those pointers lead, any workflow referencing a tag automatically starts pulling the attacker's code without any visible change in the tag name itself.

To push the deception further, the attackers cloned the original commit metadata: author names, email addresses, timestamps, and commit messages. The malicious commits appeared virtually identical to the legitimate ones they replaced. The forgery did leave subtle traces — missing cryptographic signatures and inconsistent timestamp relationships — but those aren't things most automated pipelines or developers would catch in a routine check.

This same tag manipulation technique was used in the compromise of the tj-actions/changed-files GitHub Action, which affected 23,000 repositories.

Incomplete Credential Rotation: How the Attackers Got Back In

The initial Trivy compromise happened in late February, when attackers exploited a misconfigured GitHub Actions workflow that had been sitting in the repository since October 2025. The workflow was configured to trigger on external pull requests while retaining access to repository secrets — a well-documented dangerous pattern in GitHub Actions.

Through that misconfiguration, the attackers stole a personal access token (PAT) with write permissions. They used it to delete releases, rename the repository, and publish a malicious Visual Studio Code extension. The Trivy maintainers responded by rotating their credentials — but the rotation was incomplete. Some credentials were missed, and that gap was all the attackers needed to return.

Security firms Socket and Wiz both traced the root cause of this second, larger breach directly to that incomplete rotation. Trivy maintainer Itay Shakury was direct about the implications: "If you suspect you were running a compromised version, treat all pipeline secrets as compromised and rotate immediately."

The fact that this happened to a team specializing in CI/CD security makes the lesson sharper, not softer. If it can happen here, it can happen anywhere.

A Recurring Pattern Targeting GitHub Actions and Developer Pipelines

The Trivy incident isn't an isolated event — it's the latest entry in a growing pattern of attacks targeting GitHub Actions and the developer supply chain more broadly. The tj-actions/changed-files compromise used the same tag manipulation approach and was itself traced upstream to a compromise of the reviewdog/action-setup action. In 2025, the GhostAction campaign stole over 3,000 secrets from 327 GitHub users, and an attack on the nx npm package exploited a vulnerable pull_request_target workflow.

GitHub changed the default behavior of pull_request_target workflows in December 2025 to reduce exploitation risk — but the vulnerable workflow in the Trivy repository predated that change, leaving it exposed.

What Organizations Should Do Right Now

The path forward is concrete. Organizations using Trivy should:

  • Pin GitHub Actions to full commit SHA hashes rather than version tags, which prevents tag manipulation attacks entirely
  • Use the safe versions: Trivy v0.69.3, trivy-action tag 0.35.0, and setup-trivy 0.2.6
  • Search GitHub accounts for repositories named "tpcp-docs" — their presence indicates successful fallback exfiltration
  • Block the attacker's command-and-control domain and its IP address at the network perimeter
  • Rotate all pipeline secrets immediately if there's any suspicion of running a compromised version

The breach has the potential to cascade. If impacted organizations don't rotate secrets quickly, the stolen credentials could enable supply chain compromises in their own pipelines — turning victims into unwitting vectors for the next attack.

Frequently Asked Questions

Q: Which versions of Trivy were compromised in the supply chain attack?

A: The attack affected 75 of 76 version tags in trivy-action, including widely used versions such as 0.34.2, 0.33.0, and 0.18.0, as well as seven tags in setup-trivy. The only unaffected trivy-action tag was version 0.35.0. The Trivy binary itself was also compromised across multiple distribution channels including Docker Hub and GitHub releases.

Q: How did the attackers avoid detection when tampering with Trivy's GitHub tags?

A: Rather than creating new releases that would trigger notifications, the attackers force-pushed existing version tags to point to new malicious commits. They also cloned the original commit metadata — including author names, timestamps, and commit messages — making the malicious commits appear nearly identical to the legitimate ones. The only detectable traces were missing cryptographic signatures and inconsistent timestamp relationships.

Q: How did the attackers regain access to Trivy after the initial breach was discovered?

A: The Trivy maintainers rotated their credentials after the initial late-February compromise, but the rotation was incomplete — some credentials were missed. The attackers exploited this gap to return to Trivy's environment and introduce the malicious commits that led to the larger, multi-component backdoor disclosed subsequently.