In March 2026, attackers compromised Trivy, which is one of the most widely adopted open-source vulnerability scanners, maintained by Aqua Security and trusted by thousands of organizations worldwide. 

The tool that many teams relied on to protect their software supply chain became the attack vector itself.  It’s worth noting that after this compromise, several other similar attacks have occurred, so no one should be too confident that they are invulnerable.

This blog isn’t here to throw rocks at Trivy — it’s here to give you solid advice on how to both avod being the ‘first domino’ and defend yourself against the results of a component of your pipeline becoming compromised. 

The breach didn’t begin with a sophisticated zero-day exploit. It started with a misconfigured GitHub Actions workflow.  The consequences were severe: over 10,000 CI/CD workflows affected, more than 1,000 SaaS environments reportedly compromised, and a cascading chain of credential theft that extended well beyond Trivy’s own ecosystem.

This post breaks down what happened, explains the underlying risk, and offers practical steps you can take today to check whether your own GitHub configuration is exposed to the same class of attack.

What happened

The multi-stage attack unfolded over several weeks. In late February 2026, an attacker exploited a pull_request_target workflow in the Trivy repository to extract a privileged Personal Access Token (PAT) from the CI environment. Aqua Security detected the incident, swiftly rotated credentials, and disclosed it on March 1. However, the credential rotation may not have been atomic, allowing the attackers access to the new tokens.

On March 19, the attackers escalated. Rather than creating new, visibly suspicious releases, they force-pushed malicious commits to 75 of 76 existing version tags in the trivy-action repository and all 7 tags in setup-trivy. Any workflow referencing those tags — even one “pinned” to a specific version — would silently pull the attacker’s code on its next run. This method exploits a ‘feature’ of git tags - they are mutable. Version X.y.z can be silently updated with new code - only the SHA change signals a difference. 

By March 22, malicious Docker Hub images had also been published. The payload was a sophisticated credential-stealing malware that targeted SSH keys, cloud provider credentials, CI/CD tokens, Kubernetes secrets, and even the memory of the runner process. Stolen data was encrypted and exfiltrated to a typosquatted domain that appeared to be a legitimate Aqua Security URL.

The breach was assigned CVE-2026-33634 with a CVSS score of 9.4 (Critical).

What came next: from one token to thousands of compromised environments

The initial breach — a single stolen Personal Access Token — was only the beginning. What made this incident so damaging was the cascade of compromises that followed, each one enabled by the access gained in the previous stage.

Weaponizing a trusted tool. With write access to Trivy’s repositories, the attackers injected a sophisticated infostealer into the GitHub Actions that thousands of organizations already ran as part of their CI/CD pipelines. Every time a workflow is triggered (on a pull request, a merge, or a scheduled scan), the malicious code is executed silently alongside the legitimate Trivy scan.

Because Trivy is a security scanner, it is typically granted broad access by design. Organizations routinely give it read access to source code, container images, and infrastructure configurations. The attackers exploited this inherent trust to reach assets that a less-privileged actor would never have touched.

Credential harvesting at scale. The payload, self-described as the “TeamPCP Cloud stealer,” was designed to extract every credential it could find in the CI/CD runner environment. It swept over 50 filesystem paths for SSH private keys, scraped environment variables for cloud provider access keys (AWS, GCP, Azure), collected CI/CD tokens for GitHub, GitLab, and Jenkins, and harvested Kubernetes service account tokens and kubeconfig files.

It went further than the filesystem. The stealer queried the AWS Instance Metadata Service (IMDS) at 169.254.169.254 to obtain IAM role credentials from the runner itself. Most notably, it dumped the memory of the GitHub Actions runner process via /proc/<pid>/mem to extract ephemeral secrets that existed only in RAM, such as tokens that would never appear on disk or in environment variables.

Exfiltration and secondary compromise. Stolen credentials were encrypted using AES-256-CBC with RSA-4096 key wrapping and sent to a typosquatted domain (scan.aquasecurtiy[.]org, with transposed letters) designed to blend into network logs. As a fallback, the malware used stolen GitHub tokens to create public repositories in the victims’ own accounts and uploaded the encrypted data as release assets, turning the victims’ infrastructure into an exfiltration channel.

The stolen credentials then fueled further attacks. Investigators linked the Trivy breach to the subsequent compromise of LiteLLM, an AI middleware library embedded in approximately 36% of cloud environments. Credentials harvested from Trivy’s CI/CD runners gave the attackers a foothold in downstream organizations that had never directly used Trivy at all.

The blast radius

• 1,000+ SaaS environments reportedly compromised through credential theft
• 10,000+ CI/CD workflows executed the malicious payload
• Downstream victims affected through secondary compromise (including LiteLLM)
• Stolen access reportedly handed off to Lapsus$ for extortion campaigns

How it worked: The pull_request_target anti-pattern

The root cause was a well-documented but commonly overlooked GitHub Actions misconfiguration.

GitHub’s pull_request_target event lets workflows run in the context of the base repository when a pull request is opened, even if that PR comes from an external fork. This means the workflow has access to the base repository’s secrets, tokens, and write permissions.

The danger arises when such a workflow checks out code from the incoming pull request and then executes it. In that scenario, untrusted code from any external contributor runs with full access to your repository’s secrets.

The attack flow:

1. Attacker submits a pull request from a fork
2. The pull_request_target workflow checks out the PR’s code
3. Attacker’s code executes with access to repository secrets
4. Privileged Personal Access Token (PAT) is exfiltrated

This pattern is not new. Despite there being some valid use cases, GitHub’s own security documentation warns against it, and static analysis tools (including our own) have flagged it for years. In Trivy’s case, the misconfiguration was introduced in October 2025 and was publicly identified by Boost Security’s poutine tool on November 29, 2025 — more than three months before the attackers exploited it.

Why version pinning wasn’t enough

Many security-conscious organizations pin their GitHub Actions to specific version tags, for example, trivy-action@v0.33.0 rather than @latest. This is a widely recommended best practice, and under normal circumstances, it provides a meaningful layer of protection.

But git tags are mutable. They can be force-pushed to point to a different commit at any time. The Trivy attackers exploited this by rewriting the tags themselves, so workflows that were already “pinned” to a specific version silently pulled malicious code without any visible change in the workflow file.

The only way to reference a truly immutable artifact in GitHub Actions is to pin to a full commit SHA (e.g., trivy-action@a1b2c3d4e5f6...). Unlike tags, commit hashes cannot be rewritten.

The bigger picture: GitHub Actions are dependencies

This incident illustrates a blind spot in most organizations’ security posture: GitHub Actions are dependencies and deserve the same level of scrutiny as any library in your application code.

Every Action you reference in a workflow is an open-source component with its own maintainers, its own supply chain, and access to some of your most sensitive assets: repository secrets, cloud credentials, and deployment tokens. Most organizations have mature processes for vetting application dependencies using SCA scanners, generating SBOMs, and performing license compliance checks. Very few apply the same rigor to their CI/CD toolchain.

This breach, and similar ones, are a clear signal that this needs to change. And the good news is that many of the risks are detectable and preventable with the right tooling and configuration practices.

Three things to check today

Regardless of whether you use Trivy or any other third-party Action, the following checks are worth running across your GitHub organization right now.

1. Audit your pull_request_target workflows

Search your workflow files for any use of the pull_request_target trigger. If any of these workflows check out code from the incoming pull request (rather than the base branch) and then run build, test, or script commands against it, that untrusted code executes with full access to your repository secrets. This is the exact pattern that enabled the Trivy breach.

If you find this pattern, either refactor the workflow to avoid checking out untrusted code in a privileged context or add explicit safeguards, such as restricting checkouts to the base branch.

2. Pin Actions to commit SHAs, not tags

Review how your workflows reference third-party Actions. If you’re pinning to version tags (e.g., @v2 or @v0.33.0), those references can be silently changed by anyone with write access to the upstream repository. Switch to full commit SHA pinning for any Action that has access to secrets or runs in a privileged context. 

NOTE: SHA pinning does not protect you from transitive dependencies, and the SHA could potentially still point to an orphan commit in a fork created by an attacker. Any later change to the SHA (in a Dependabot PR to update the action, for instance)  should be carefully reviewed. 

Yes, SHA pinning makes updates less convenient. But it’s the only way to guarantee that what you tested is what runs in production. 

3. Scope your token permissions

Set GITHUB_TOKEN to read-only by default at the organization level, and grant write permissions only where explicitly needed. Avoid passing secrets: inherit or toJSON(secrets) to reusable workflows. Both patterns expose all secrets to every job in the chain, which dramatically increases the blast radius if any single Action is compromised.

How Endor Labs can help

At Endor Labs, we treat GitHub Actions as first-class dependencies — because that’s what they are. Our platform includes purpose-built policies that automatically identify the workflow misconfigurations and repository settings that put your CI/CD pipelines at risk.

The misconfiguration that enabled the Trivy breach existed in the repository for four months before it was exploited. Automated policy enforcement would have flagged it as a high-severity finding from the moment it was introduced, giving the team a clear window to remediate before any damage was done.

Moving forward

Trivy and similar breaches are not a reason to panic. They are clear, well-documented examples of a risk category that the industry is still learning to address. CI/CD pipeline security is an evolving discipline, and incidents like this one help the entire community sharpen its practices.

The practical takeaway is straightforward enough: apply the same rigor to your CI/CD dependencies as you do to your application dependencies (you do scan your dependencies, right?). Audit your workflows, tighten your permissions, pin to immutable references, and consider tooling that can automate these checks continuously.

Further Reading

• GitHub Security Advisory: GHSA-69fq-xp46-6x23
• Endor Labs: Surprise! Your GitHub Actions Are Dependencies, Too
• Endor Labs: GitHub Action Security Policies Documentation

‍