The Trivy supply chain attack hit developers and CI/CD pipelines because attackers remained inside the software supply chain after an earlier credential exfiltration, repointed official tags and releases on March 19, 2026, and executed an infostealer before the actual scan. As a result, compromised workflows initially appeared normal even though secrets could already have been harvested.
Trivy Supply Chain Attack Hits Releases, Actions, and the Chain of Trust
The Trivy supply chain attack was not caused by an ordinary vulnerability, but by the compromise of the official software supply chain. The incident affected not just isolated artifacts, but the trivy v0.69.4 release as well as the two GitHub Actions aquasecurity/trivy-action and aquasecurity/setup-trivy. The risk was severe: teams that had integrated Trivy into automated build and scan workflows could trust unchanged version references on paper while still executing malicious code behind the scenes.
According to Aqua’s security advisory on GitHub, an attacker used compromised credentials on March 19, 2026, to publish the official trivy v0.69.4 release, repoint 76 out of 77 version tags in trivy-action to malicious commits, and replace all seven tags in setup-trivy. The most sensitive aspect is that this was not just the insertion of a suspicious new version. The attackers rewrote existing tags that were already known and widely used in pipelines. Workflows that trusted @0.x.y instead of a fixed commit SHA could therefore pull compromised code on the next run without any visible change in the workflow definition itself.
How the Trivy Supply Chain Attack Became Possible
The most important new finding is that the March 19 incident did not emerge out of nowhere. According to Aqua’s current incident update, the attack chain began as early as late February 2026. At that stage, attackers exploited a misconfiguration in Trivy’s GitHub Actions environment, stole a privileged access token, and gained access to automation and release processes. Aqua has so far deliberately described the root cause in general terms as a misconfiguration. Community and incident-response analyses describe the initial entry path more technically as a risky pull_request_target scenario, in which public repositories can run externally triggered workflows with elevated privileges.
The later impact was made possible by the incomplete cleanup after the first incident on March 1. Aqua states openly that secrets and tokens were rotated, but that the process was not atomic. That created a multi-day window in which the already embedded attacker could capture newly issued credentials or credentials that had not yet been revoked at the same time.
How the Second Phase of the Trivy Supply Chain Attack Unfolded
On March 19, the attackers used this residual access to abuse the official chain of trust directly. The suspicious activity began at around 18:43 (GMT+1) with the manipulated Actions tags. According to Aqua, the compromised trivy v0.69.4 release was publicly available roughly between 19:22 and 22:42. For setup-trivy, the exposure window ended that same evening at around 22:44, while trivy-action remained affected until March 20 at about 06:40. These precise time windows matter operationally because they allow GitHub workflow runs, artifacts, and runner logs to be narrowed down very precisely.
Technically, the attack unfolded in several stages. In the trivy v0.69.4 release, a manipulated commit was prepared so that, instead of legitimate code, a malicious component could be fetched from a typosquatted domain; according to the advisory, validation in the release chain was also bypassed. Even more dangerous was the tag manipulation in the GitHub Actions. There, write access alone was enough to repoint tags to different commits via force-push. This exact mechanism is also described in CrowdStrike’s technical analysis: Git tags are convenient, but mutable. That makes them practical as CI/CD version anchors, yet inherently vulnerable from a supply chain security perspective.
Why Developers and Pipelines Barely Noticed the Attack
The injected malware was positioned so that it executed before the actual Trivy scan. That is why many affected workflows could still appear normal on the surface. The job continued to produce what looked like a legitimate scan result while sensitive data was being collected from runner memory and the local file system in the background. Aqua lists SSH keys, AWS, GCP, and Azure credentials, Kubernetes tokens, Docker configurations, .env files, Git credentials, and database credentials among the targeted data. Anyone affected during this window should therefore not treat a green pipeline run as a sign of safety.
There was also a fallback path for exfiltration. If direct data exfiltration failed and a suitable GitHub token was present, the malware was designed, according to Aqua, to create a public repository named tpcp-docs in the victim’s account and store the collected data there as a release asset.
As part of incident response, teams should therefore investigate GitHub audit logs, newly created repositories, release artifacts, and bot activity across organizational accounts.
The Trivy Supply Chain Attack Did Not End with Secret Theft
The Trivy incident did not stop at the theft of CI/CD secrets. According to current analyses, the compromised attack chain established additional persistence on affected developer systems and runners, meaning the risk extended well beyond the pipeline run itself. CrowdStrike describes how the malware ran before the legitimate Trivy scan and could harvest credentials without raising immediate suspicion, while Aqua classifies the incident as a multi-stage campaign whose origins go back to a compromise of the GitHub Actions environment in late February.
The second escalation stage is especially serious: according to the available analyses, the downstream infrastructure relied on an ICP-based dead-drop mechanism that allowed compromised systems to retrieve additional payloads. At the same time, the campaign spread into the npm ecosystem. As The Hacker News reported based on technical analyses, at least 47 npm packages were compromised as part of the so-called CanisterWorm campaign; their postinstall hooks searched for tokens, downloaded additional malicious components, and used compromised publisher privileges for further propagation. As a result, the Trivy incident evolved from a supply chain compromise into a much broader, self-propagating ecosystem threat.
Which Versions Were Affected and What Is Considered Safe Now
The compromised versions include trivy v0.69.4, all trivy-action tags from 0.0.1 through 0.34.2, and all setup-trivy tags from v0.2.0 through v0.2.6. Aqua lists trivy v0.69.3, trivy-action 0.35.0, and setup-trivy 0.2.6 as safe target versions. Environments that pulled containers by digest rather than by tag, or that had already pinned GitHub Actions to full commit SHAs, were not affected.
Trivy Supply Chain Attack Lessons Learned
The immediate operational takeaway is clear: every pipeline that executed an affected version during the known exposure windows should be treated as potentially compromised. That means rotating all secrets without exception, including cloud keys, registry tokens, deployment keys, GitHub tokens, and any other credentials available on runners. In self-hosted runner environments, simply updating to a clean version is not enough, because additional local files and credentials may already have been accessed.
Strategically, the case is as uncomfortable as it is instructive. A security tool itself became the distribution channel for an infostealer because a previously stolen token, incomplete remediation, and trust in mutable tags came together. The Trivy supply chain attack shows that modern software supply chains must not only be scanned for vulnerabilities, but also hardened against the abuse of their own automation privileges. Anyone whose only lesson is “upgrade to the next clean version” is missing the point. The real consequence is this: pin GitHub Actions to commit SHAs, sharply reduce token privileges, carry out rotations completely and simultaneously, and monitor CI/CD runners as if they were critical production systems.
The frequently cited attribution to TeamPCP remains secondary. From a defensive standpoint, what matters more right now is that the cause, the attack flow, and the affected versions are now described with growing confidence. The case is especially notable because it shows how quickly an attack on the build and release layer of a security tool can become a direct risk to developers, organizations, and downstream software supply chains.
