Trivy GitHub Actions Compromise 2026: Why Your CI/CD Still Isn't Safe

The recent Trivy GitHub Actions compromise, where a security scanner designed to find vulnerabilities was backdoored *again*, should deeply concern you. Not just once, but twice in a month. On March 21, 2026, we learned that Trivy, Aqua Security's widely used open-source vulnerability scanner, had been compromised with credential-stealing malware injected into its official releases and GitHub Actions. This isn't just an isolated incident; it's a stark reminder that our CI/CD pipelines are still incredibly vulnerable, and the problem goes deeper than just "pin your SHAs."

The developer community, understandably, is frustrated. I've seen discussions online questioning how a security vendor could have a repeated compromise, especially when the first one should have triggered a complete overhaul of their security posture. It's an uncomfortable truth: if a tool meant to secure your supply chain becomes the attack vector, what can you really trust?

How a Stolen PAT Led to Widespread Compromise

Let's break down what actually happened. This wasn't a new, sophisticated zero-day. This was a "second bite at the apple" scenario, stemming from an incomplete cleanup after an earlier breach in late February 2026.

The First Breach (Late February 2026): Attackers exploited a misconfigured GitHub Actions workflow that had been sitting there since October 2025. This workflow was dangerous because it ran with access to repository secrets, even when triggered by external pull requests. That's a fundamental security flaw. The result? Attackers stole a Personal Access Token (PAT) that had write permissions. They then used this PAT to delete releases, rename the repository, and even publish a malicious Visual Studio Code extension.

The Second Breach (March 2026): Here's where the incomplete cleanup comes in. After the first incident, Aqua Security rotated credentials, but it wasn't a fully atomic process. The attackers still had access to a valid PAT. They used this PAT to force-push malicious code to 75 out of 76 existing version tags in the aquasecurity/trivy-action repository. This means if your workflow referenced @0.34.2 or @0.18.0, you were pulling malicious code.

They also compromised setup-trivy and several Trivy binary Docker image tags, including 0.69.4, 0.69.5, 0.69.6, and even the latest tag for a period. This second Trivy GitHub Actions compromise highlights the persistent threat.

The attackers were clever about it. They didn't create new releases; they overwrote existing, trusted tags. To avoid detection, they cloned the original commit metadata—author names, email addresses, timestamps, and commit messages. But there were traces: the malicious commits were unsigned (the originals were GPG-signed), and while they claimed old release dates, their parent commit was dated March 2026. Also, these malicious commits only modified entrypoint.sh, whereas legitimate updates usually touch multiple files.

The Infostealer: What It Does

The injected malware, self-identified as "TeamPCP Cloud stealer" (a group also known as DeadCatx3, PCPcat, or ShellForce), is designed to steal credentials from CI/CD environments. It's a nasty piece of work:

• Parallel Execution: It runs its malicious code *before* the legitimate Trivy scan, making it harder to spot.
• Secret Scraping:
  • On GitHub-hosted Linux runners, it uses sudo to locate the Runner.Worker process, parses its memory maps, and dumps memory from /proc/<pid>/mem. It then greps for JSON patterns like {"value":"<secret>","isSecret":true}.
  • On self-hosted runners or non-Linux environments, it executes a Python script to scour the filesystem.
• Targeted Data: This isn't just GitHub tokens. It goes after SSH keys, cloud provider credentials (AWS, GCP, Azure), Kubernetes tokens, Docker registry configurations, database credentials (.pgpass, .my.cnf), CI/CD config files (terraform.tfvars, Jenkinsfile), environment variables, shell history, and even cryptocurrency wallets.
• Persistence: It installs a Python dropper on developer machines, phoning home every five minutes for more payloads.
• Exfiltration:
  • Primary method: Encrypted data sent via HTTPS POST to a typosquatted domain: scan[.]aquasecurtiy[.]org.
  • Fallback method: If the primary fails and a user-scoped GitHub PAT (INPUT_GITHUB_PAT) is available, it creates a public repository named tpcp-docs on the victim's GitHub account and uploads the encrypted data as a release asset. This is a particularly insidious fallback because it uses *your* account to exfiltrate *your* data.

The malware deployed during the Trivy GitHub Actions compromise is sophisticated and far-reaching.

The Real Impact of the Trivy GitHub Actions Compromise

This incident affects over 10,000 workflow files on GitHub that reference aquasecurity/trivy-action. If your CI/CD pipeline ran any of the compromised version tags after approximately 19:00 UTC on March 19, 2026, you should assume *all* secrets accessible to that workflow are compromised.

The irony of a security scanner becoming an attack vector is not lost on anyone. It highlights a critical vulnerability in our software supply chain: the implicit trust we place in third-party dependencies, especially when they're fetched by mutable tags. This isn't just about Trivy; it's about every GitHub Action, every Docker image, every package we pull into our build systems. Tools like Dependabot and Renovate, while helpful, can also inadvertently spread these malicious tags if not configured to pin to immutable SHAs.

What We Need to Do Now

Aqua Security has provided immediate recommendations, which you can find on their official blog, and you need to act on them:

• Rotate Everything: Treat all pipeline secrets as compromised and rotate them immediately. This includes cloud credentials, SSH keys, API tokens, database passwords, and Docker registry tokens.
• Pin to SHAs: Immediately stop using trivy-action by version tag. Pin your GitHub Actions to the full commit SHA hash (e.g., 57a97c7e7821a5776cebc9bb87c984fa69cba8f1) or use the unaffected trivy-action tag 0.35.0. For the Trivy binary, use v0.69.3, and for setup-trivy, use 0.2.6.
• Check for Exfiltration: Search your GitHub accounts for any repositories named tpcp-docs. This is a clear indicator of successful fallback exfiltration.
• Block C2: Block the command-and-control domain scan[.]aquasecurtiy[.]org and its IP address at your network perimeter.
• Audit Logs: Review GitHub Actions logs for trivy-action runs after March 19, 2026.

But these are just immediate fixes. We need to address the systemic issues this incident exposed:

• Mutable Tags are a Design Flaw: While SHA pinning is a necessary mitigation, it's not a complete solution. It prevents *future* tag manipulation, but it doesn't solve the problem of initial trust or the risk of pinning to an *already compromised* SHA. The industry needs to move towards a model where all references are immutable by default, or where cryptographic attestations are universally enforced.
• Least Privilege is Non-Negotiable: The initial compromise stemmed from a workflow running with excessive permissions. CI/CD environments must operate on the principle of least privilege, with secrets scoped narrowly and ephemeral where possible.
• Atomic Credential Rotation: The "second bite" highlights that credential rotation after a breach must be comprehensive and atomic. Any lingering access is an open door.
• Assume Compromise: The lessons from the Trivy GitHub Actions compromise reinforce that we need to treat our CI/CD environments and the dependencies we pull into them as potentially hostile. This means robust runtime monitoring, behavioral analysis, and strong egress filtering.
• Beyond GitHub's Changes: GitHub's changes in December 2025 to pull_request_target workflows were good, but older, misconfigured workflows (like Trivy's) remained vulnerable. We can't rely solely on platform defaults; we need to actively audit our own configurations.

This isn't just a Trivy problem; the Trivy GitHub Actions compromise serves as a stark warning about a CI/CD supply chain problem that affects all of us. We need to move beyond basic recommendations and implement architectural changes that build resilience even when trusted components fail. Trust in open source is earned, and incidents like this make it harder. We have to build systems that can withstand these attacks, because they're not going away.