- Endor Labs reports that attackers stole a token from Trivy's GitHub setup, then rewrote version tags so pinned workflows ran credential-stealing code.
- The lesson: a version tag is a label that can be changed, so CI/CD tools need the same scrutiny as application code.
- Teams should audit pull_request_target workflows, pin privileged Actions to full commit IDs, and set GITHUB_TOKEN to read-only by default.
Most companies treat their security scanner as a guard at the door. The Trivy breach shows it can also hold broad access to everything inside. The lesson is simple: a version tag is a name, not a seal. Anyone with write access can point that name at different code.
What happened
Endor Labs, a software supply chain security vendor, published an analysis of the March 2026 compromise of Trivy. Trivy is an open-source vulnerability scanner maintained by Aqua Security. According to Endor Labs, the attack began in late February with a misconfigured GitHub Actions workflow, not a zero-day flaw.
Aqua Security disclosed the incident on March 1, after changing the credentials involved. Endor Labs says the changeover may not have happened all at once. That could have left the attackers able to obtain the replacement tokens.
On March 19, the attackers moved 75 of the 76 existing version tags in the trivy-action repository so they pointed at malicious commits. All 7 tags in setup-trivy were changed the same way. By March 22, malicious images had also been published to Docker Hub. The breach carries CVE-2026-33634 and a CVSS score of 9.4.
How the attack worked
The entry point was a GitHub feature called pull_request_target. It runs a workflow with the base repository's secrets, even when the pull request comes from an outside fork. That is fine until the workflow also checks out the outsider's code and runs it. Then an unknown contributor's code runs with the repository's secrets.
Endor Labs says this pattern is documented in GitHub's own guidance. It says Boost Security's poutine tool flagged the Trivy misconfiguration on November 29, 2025. That was more than three months before the attackers used it. The warning existed, and the fix did not arrive in time.
The second step was the tags. A git tag is a movable label. The attackers repointed existing version tags at malicious commits. A workflow pinned to a specific version, such as v0.33.0, pulled the new code on its next run. Nothing in the workflow file changed.
What the malware took
Endor Labs describes the payload as a credential stealer that called itself "TeamPCP Cloud stealer." It searched more than 50 file paths for SSH keys and read environment variables for AWS, GCP and Azure keys. It also collected tokens for GitHub, GitLab and Jenkins, plus Kubernetes credentials.
The code also dumped the working memory of the process that runs the GitHub Actions job. That exposes short-lived secrets that are never written to disk. Stolen data was encrypted and sent to a lookalike domain with transposed letters. As a fallback, the malware used stolen GitHub tokens to publish the data in public repositories inside the victims' own accounts.
Why the impact reaches past the first victim
A scanner is granted broad access by design. It reads source code, container images and infrastructure settings. Compromise the scanner and you inherit that reach. Endor Labs reports more than 1,000 SaaS environments were compromised. It also says investigators linked the breach to a later compromise of LiteLLM, an AI middleware library.
Those are Endor Labs' reported figures. It also says stolen access was reportedly handed to Lapsus$ for extortion. We have not seen independent counts, so read them as reported.
This shows a shift in where risk sits. Companies vet the libraries in their products with care. Few give the same scrutiny to the automation that builds and ships those products. That automation holds the deployment keys, which makes it an attractive target.
What leaders should ask their teams
Endor Labs sells tooling in this area, so weigh its pitch accordingly. Its checks are still concrete and cheap to run.
First, ask: which of our workflows use pull_request_target, and do any run code from an outside pull request? If so, refactor them or restrict checkouts to the base branch.
Second, ask: do our privileged Actions point to version tags or full commit IDs? Endor Labs advises pinning to the full commit ID for any Action that touches secrets. It adds a caveat: pinning does not cover transitive dependencies. Any later change to a pinned ID should be reviewed.
Third, ask: is GITHUB_TOKEN read-only by default across the organization? Also check whether any workflow calls a reusable workflow with "secrets: inherit" or toJSON(secrets). Endor Labs says both patterns make every secret available to every job in the chain, so teams should replace them with explicit, minimal secret passing.
Trivy was flagged for months before it was exploited. The question for your next board update is not whether you own a scanner. It is who can change the code your scanner runs, and who would notice.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Endor Labs.
