Trivy Supply Chain Attack Poisons 76 GitHub Action Tags in CI/CD

A security scanner turned into a credential stealer

DevOps teams add vulnerability scanners to their pipelines so they can catch threats before release. In March 2026, one of the most popular of those scanners became the threat. On March 19, an attacker used compromised credentials to publish a malicious Trivy v0.69.4 release. The same actor force-pushed 76 of the 77 version tags in aquasecurity/trivy-action so they pointed at credential-stealing code, and replaced all seven tags in aquasecurity/setup-trivy with malicious commits, according to Aqua Security's own advisory.2

The exact numbers differ slightly depending on who is counting. Socket, Snyk and Upwind report 75 of 76 trivy-action tags rewritten, while Aqua's advisory and Kaspersky say 76 of 77.5106 The gap probably comes from how each one counted the single tag that stayed clean. Every account agrees on what matters: only 0.35.0 was untouched, and the reason is that it was covered by GitHub's immutable releases feature, which Aqua had turned on March 4.

Researchers attribute the campaign to TeamPCP, a group also tracked as DeadCatx3, PCPcat and ShellForce. Part of the evidence is blunt: the harvester's own code labels it "TeamPCP Cloud stealer."512

How a moved tag hit thousands of pipelines

The delivery method deserves more attention than the malware. A Git tag only points to a commit. Anyone with write access can force-push it somewhere new, and a workflow that references @v0.33.0 will run whatever that tag points to when the job starts.10 Teams' workflow files never changed, yet their pipelines ran attacker code.1

The attacker also worked to avoid detection. The malicious commits reused the original authors' names and timestamps, which made the Git history look normal.1 Socket researcher Philipp Burckhardt noted one telltale sign: the genuine commits carried GitHub GPG signatures, and the attacker's commits had none.11 The poisoned entrypoint.sh ran its stealer first and then ran a real Trivy scan, so builds kept passing and scan output looked as expected.511

The payload read GitHub Actions secrets straight out of the Runner.Worker process memory, which gets around the runner's log masking. It also searched more than 50 filesystem paths for SSH keys, cloud credentials, Kubernetes tokens, Docker configs, .env files and cryptocurrency wallets.8 The stolen data was encrypted with AES-256-CBC, wrapped with RSA-4096, and sent to the typosquatted domain scan.aquasecurtiy[.]org.11 If that upload failed, the malware used the victim's own GitHub token to create a public repository called tpcp-docs and stored the stolen data there.13

The exposure windows varied by component. Aqua says the malicious binary was live for about three hours, setup-trivy for about four, and trivy-action for about twelve, from roughly 17:43 UTC on March 19 to 05:40 UTC on March 20.16 More than 10,000 GitHub workflow files reference trivy-action, according to Socket and Snyk.517 Twelve hours was long enough for a large number of scheduled and push-triggered builds to run the stealer.

The real root cause: a cleanup that didn't finish

The March 19 attack was the second wave. The first started weeks earlier with a pull_request_target workflow that had been in the Trivy repository since October 2025. Boost Security's poutine tool flagged it on November 29, 2025, more than three months before anyone exploited it.5 On February 28, an automated account called hackerbot-claw used that workflow to steal an org-scoped personal access token belonging to the aqua-bot service account. With it, the attacker briefly made the repository private, deleted releases, and pushed a malicious VS Code extension to OpenVSX.54

Aqua disclosed the breach on March 1 and rotated credentials. Aqua's advisory says that rotation was not atomic, meaning the credentials were not all revoked at once. During a window of a few days, an attacker holding a still-valid token could have copied the new secrets as they were issued.2 Itay Shakury, Aqua's VP of open source, said publicly that the company changed its secrets and tokens but the process wasn't atomic. He said Aqua is now locking down all automated actions and tokens.18

This is the most useful lesson for DevOps teams. The attacker did not need a new exploit for the second wave. Burckhardt said the attacker had valid credentials with enough privilege to push code and rewrite tags.18 In my view, the scanner was not the main failure. The failures were credential hygiene and incident response, and they happened at a vendor whose business is security.

From one repository to a whole ecosystem

The second wave did not stay inside Aqua's repositories. On March 22, the attacker pushed backdoored Docker images tagged 0.69.5 and 0.69.6 directly to Docker Hub using separately compromised Docker Hub credentials. No matching GitHub releases existed.2 The same day, all 44 repositories in Aqua's internal aquasec-com organization were defaced within about two minutes. Phoenix Security described the incident as still not contained as of March 23.8

Npm tokens stolen in the attack powered CanisterWorm, a self-propagating worm that compromised 47 or more npm packages. Its command-and-control used an Internet Computer Protocol canister as a dead drop.8 In one wave, 28 packages were compromised in under a minute.1 The same credential stealer then turned up in Checkmarx's AST GitHub Action four days after the Trivy attack, using a different domain, according to Sysdig's findings. LiteLLM, an AI gateway library that used Trivy in its pipeline, had versions 1.82.7 and 1.82.8 poisoned on PyPI for about five hours on March 24.6 Kaspersky also reports a destructive branch: the malware wipes Kubernetes clusters on systems that show a Tehran time zone or Farsi as the main language.6

Estimates of the total damage vary widely, and readers should treat the larger figures with caution. Arctic Wolf cites reports that at least 1,000 enterprise SaaS environments may be affected.9 Kaspersky says more than 20,000 repositories are potentially vulnerable and notes the attackers' own claims of hundreds of gigabytes stolen.6 Phoenix calls it the most consequential CI/CD supply chain attack since SolarWinds. Palo Alto Networks calls it the most sophisticated supply chain attack on a security tool so far.81 The second claim holds up well. The SolarWinds comparison is harder to support, because the confirmed exposure windows were measured in hours, not months.

Reporting on the formal tracking also changed over time. Early coverage from Snyk and Phoenix said no CVE had been assigned.58 Later reporting gives the identifier CVE-2026-33634 with a CVSS score of 9.4.4

What DevOps teams should change

The immediate fixes are well documented. Safe versions are Trivy 0.69.3, trivy-action 0.35.0 and setup-trivy 0.2.6. Aqua says workflows pinned to a commit SHA were not affected.1315 Because the attacker's force-push caused GitHub to treat the hijacked tags as immutable releases, Aqua could not recreate the original tag names. It republished the legitimate commits under new v-prefixed tags instead, so pipelines that use the old names need to be updated.

Any team that ran an affected component during the exposure windows should treat every secret the runner could reach as stolen. That includes GitHub tokens, cloud keys, registry credentials, database passwords and SSH keys. Teams should also check their GitHub accounts for unexpected tpcp-docs repositories.134 On developer machines, the backdoored binary installed a persistent systemd user service, so rotating credentials alone does not clean up a workstation.8

SHA pinning is the main recommendation across the coverage, and Wiz researcher Rami McCarthy repeated it.18 It has limits, though. The poisoned release workflow referenced an actions/checkout hash that looked legitimate but actually pointed to a commit from a fork.5 StepSecurity points out that GitHub tags can resolve to commits pushed through forks.16 So pinning protects you only if someone checks that the hash belongs to the real upstream repository.

Snyk's broader list is a reasonable baseline for platform teams:14

• Audit pull_request_target workflows.
• Prefer repo-scoped tokens over org-scoped PATs.
• Monitor outbound traffic from CI runners.
• Require signed release commits.
• Rotate credentials completely and all at once.

Security tools usually run with broad permissions inside the pipeline, which is exactly why attackers want to compromise them. That level of access calls for more scrutiny of those tools, not less.