Trivy, one of the most widely used open-source vulnerability scanners, was compromised for the second time in three weeks. Threat actors hijacked 75 of 76 version tags in the trivy-action GitHub repository, replacing the security scanner with credential-stealing malware that harvested secrets from CI/CD pipelines.
The malicious code was live for up to 12 hours. Anyone who ran a Trivy scan during that window had their pipeline secrets exfiltrated to attacker-controlled infrastructure, including cloud credentials, SSH keys, API tokens, and cryptocurrency wallet keys.
What Happened
On March 19, 2026, attackers force-pushed malicious commits to nearly every version tag in the aquasecurity/trivy-action repository. They replaced the legitimate entrypoint.sh with a 204-line credential-stealing script, then updated tags v0.0.1 through v0.34.2 to point to the compromised code. Only v0.35.0 remained clean.
The attackers also compromised:
- setup-trivy GitHub Action (7 tags force-pushed)
- Trivy binary v0.69.4 (malicious release published)
- Docker images 0.69.5 and 0.69.6 (published after initial compromise)
This wasn’t a zero-day exploit. The attackers used stolen credentials from a previous breach on February 28, 2026. Incomplete incident response left tokens accessible, allowing the same threat actors to return three weeks later with a more sophisticated attack.
How the Attack Worked
The malware operated in three stages, according to Socket’s analysis:
Collection. On GitHub-hosted runners, the payload used privileged sudo access to dump process memory from the Runner.Worker .NET heap, extracting secrets marked as sensitive. On self-hosted runners, it scanned over 50 file paths for SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes tokens, and environment configuration files.
Encryption. Harvested data was encrypted using AES-256-CBC with a randomly generated session key, then wrapped with an RSA-4096 public key using OAEP padding.
Exfiltration. The encrypted bundle was sent to a typosquatted domain: scan[.]aquasecurtiy[.]org (note the misspelling). If that failed and a GitHub token was available, attackers created a public repository called “tpcp-docs” in the victim’s account and uploaded the stolen data as a release asset.
The malware self-identified as “TeamPCP Cloud stealer” in its source code. TeamPCP is a documented cloud-native threat actor known for targeting misconfigured Docker APIs, Kubernetes clusters, and CI/CD infrastructure.
Who Was Affected
Any organization running Trivy scans via GitHub Actions between March 19, 2026 (~19:15 UTC) and March 20, 2026 is potentially compromised. StepSecurity’s analysis found 45 of 767 prominent public repositories confirmed compromised, with 5 having custom secrets exposed.
The impact extends beyond public repositories. Private enterprise pipelines using the same GitHub Actions would have executed the same malicious code. The attackers had access to any secret explicitly referenced in workflows via ${{ secrets.* }}, though unreferenced organization-level secrets were not accessible.
Key targets included:
- GitHub tokens (automatically available in all workflows)
- AWS, GCP, and Azure credentials
- Docker registry tokens
- Kubernetes secrets and configs
- SSH keys and Git credentials
- Terraform state files
- Cryptocurrency wallet keys
The Second Breach Problem
This is the second Trivy compromise in three weeks. The initial February 28 incident involved an autonomous bot called hackerbot-claw exploiting a pull_request_target workflow to steal a Personal Access Token. Attackers used that token to gain full repository access.
Aqua Security’s incident response was incomplete. The attackers retained access to refreshed tokens, allowing them to return on March 19 with a more comprehensive attack. Evidence suggests they even published internal Aqua repositories publicly on GitHub before proceeding with the credential harvesting campaign.
The original incident discussion (#10265) was deleted to suppress awareness. When community members raised questions about the second compromise in discussion #10420, a spam bot flood—17 accounts posting in one second—attempted to bury the thread.
What This Means
Security tools are high-value targets. An attacker who compromises a vulnerability scanner gets access to every pipeline that runs it, often with elevated privileges. The irony is painful: the tool organizations trusted to find vulnerabilities became the vulnerability.
This follows a pattern of CI/CD-focused supply chain attacks. The tj-actions/changed-files compromise in 2025 demonstrated the same technique. Version tags in GitHub Actions can be force-pushed by anyone with write access, making them fundamentally unreliable as trust anchors.
Microsoft published official guidance on detecting and defending against this specific compromise, indicating the scale of enterprise exposure.
What You Should Do
Stop using version tags. Pin GitHub Actions to full commit SHAs, not version numbers. The only safe trivy-action reference is commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 or tag 0.35.0.
Rotate everything. If you ran trivy-action between March 19-20, 2026, assume all secrets in that workflow are compromised. Rotate cloud credentials, SSH keys, API tokens, registry credentials, and database passwords immediately.
Search for fallback repositories. Check your GitHub organization for any repository named “tpcp-docs”—this indicates successful data exfiltration via the fallback mechanism.
Audit your pipeline logs. Review GitHub Actions logs for trivy-action executions after March 19, 2026, 19:00 UTC. StepSecurity published a trivy-compromise-scanner to help identify affected runs.
Update to safe versions. Use trivy v0.69.3 or earlier (0.69.4-0.69.6 are compromised), trivy-action v0.35.0 only, and setup-trivy v0.2.6.
Enable runtime detection. Tools like StepSecurity’s Harden-Runner can detect anomalous outbound connections from GitHub Actions, which is how this compromise was initially detected in community projects.
The Bigger Picture
This attack exploited a fundamental weakness in how the ecosystem handles trust. Git tags are mutable by design—anyone with write access can point them anywhere. When organizations pin to v0.34.0 instead of a specific commit SHA, they’re trusting that tag to never change. That trust was misplaced.
The attacker’s sophistication is notable. They used legitimate commit metadata (authors, timestamps, messages) copied from previous releases to make the malicious commits appear authentic. The only forensic traces were unsigned commits, impossible parent-date relationships, and single-file modifications.
If you’re securing CI/CD pipelines, this incident is a forcing function. SHA-pinning, network egress monitoring, and secret access auditing aren’t optional anymore. The tools meant to protect you are now primary targets.