The open source vulnerability scanner Trivy, widely integrated into container, Kubernetes and repository security workflows, has become the center of a significant software supply chain attack. Attackers managed to inject an infostealer into GitHub Actions and Trivy releases, putting CI/CD secrets and developer machines at risk across many organizations.
Why the Trivy GitHub Actions compromise is a high-impact incident
Trivy, maintained by Aqua Security, is one of the most popular open source scanners, with over 33,200 GitHub stars. It is deeply embedded in DevSecOps pipelines, container build processes and Kubernetes security checks. Compromising such a trusted component has a multiplier effect across the software supply chain.
According to public analysis, the attack leveraged stolen credentials to perform a force-push on 75 of 76 tags in the aquasecurity/trivy-action repository and to replace seven setup-trivy tags. As a result, widely used versions such as @0.34.2, @0.33 and @0.18.0 began pointing to malicious commits, while @0.35.0 remained intact. The trojanized release Trivy v0.69.4 was available for roughly three hours, and the poisoned GitHub Actions tags for about twelve hours.
Attack technique: retargeted GitHub tags and trojanized releases
Security researchers at Socket and Wiz observed that the threat actors did not create new commits or releases. Instead, they repointed existing tags to malicious commits that duplicated the original metadata: author name, email, timestamps and pull request references. This approach limited visible anomalies in the repository history and reduced the chance of automatic alerts.
In parallel, the attackers modified the entrypoint.sh script used by GitHub Actions and published trojanized Trivy v0.69.4 binaries via GitHub Releases, Docker Hub, GHCR and AWS ECR. During the window of exposure, any workflow referencing the compromised tags or images automatically pulled and executed the malicious code — a textbook example of a supply chain attack via a trusted security tool.
Infostealer capabilities: what data could have been exposed
The malicious code executed the legitimate Trivy scanner to avoid breaking expected behavior, while simultaneously running an infostealer designed to exfiltrate sensitive information from both CI/CD environments and developer workstations.
The stealer harvested environment variables and scanned the filesystem for high-value secrets and configuration files, including SSH keys, AWS/GCP/Azure credentials, kubeconfig files, Docker configuration, .env files, database passwords, Slack and Discord tokens, TLS private keys, VPN profiles and cryptocurrency wallet data. It also enumerated network interfaces and inspected memory regions of the GitHub Actions Runner.Worker process to locate JSON-encoded secrets.
Collected data was encrypted and sent via HTTP POST to a typosquatted domain, scan.aquasecurtiy[.]org, visually similar to Aqua Security’s legitimate domain. If exfiltration failed, the malware used an unusual fallback: it created a public repository named tpcp-docs in the victim’s GitHub account and uploaded stolen data there as an alternative exfiltration channel.
On developer machines, the trojanized binary additionally deployed a Python payload (~/.config/systemd/user/sysmon.py) registered as a systemd service. This component periodically contacted a remote command-and-control server to retrieve new payloads, providing persistent post-exploitation access.
Attribution to TeamPCP and links to wider supply chain campaigns
Threat intelligence points to the group TeamPCP (also known as DeadCatx3, PCPcat and ShellForce) as the likely actor, based in part on a “TeamPCP Cloud stealer” comment found in one of the Python scripts. Research from Socket indicates that this group focuses on cloud infrastructure attacks, frequently abusing misconfigured Docker APIs, Kubernetes clusters, Ray dashboards and Redis servers.
Security vendor Aikido has further linked this incident to a broader malicious campaign dubbed CanisterWorm, a self-propagating worm targeting npm packages. CanisterWorm uses stolen npm tokens to publish malicious package versions and can compromise dozens of projects within minutes. Its command-and-control relies on a decentralized architecture built on Internet Computer (ICP), making takedown efforts more complex. Together with earlier cases such as SolarWinds, Codecov and malicious npm ecosystems, the Trivy attack reinforces the trend of adversaries moving “left” into the development and build stages of the software lifecycle.
Root cause: VS Code extension compromise and repeated access
Trivy maintainer Itai Shakury reported that the roots of this incident trace back to an earlier attack on 1 March 2026, when the Aqua Trivy VS Code extension was compromised. That intrusion allowed attackers to obtain GitHub credentials with write access to Trivy’s repositories.
Following the March incident, Aqua Security rotated tokens, but several artifacts — including certain API keys, certificates and passwords — reportedly remained accessible. These residual credentials enabled the adversaries to regain access and orchestrate the more destructive supply chain operation. The attackers also removed references to the March compromise from the Trivy repository history, complicating forensic analysis and obscuring the full sequence of events.
Impact on organizations and practical CI/CD security measures
Who should assume compromise
Any organization that used the compromised GitHub Actions tags or Trivy binaries during the exposure window should operate under the assumption that its CI/CD and infrastructure secrets may be fully compromised. This extends beyond pipeline environment variables to any connected resources: cloud accounts, source code repositories, Kubernetes clusters, databases and messaging platforms.
Recommended response and hardening steps
Project maintainers and independent experts recommend that potentially affected users immediately rotate all secrets, including cloud credentials, SSH keys, API tokens, database passwords, OAuth tokens, VPN keys and messaging tokens. In addition, organizations should:
- Review all CI/CD pipelines and GitHub Actions logs for unusual job runs, outbound connections and repository changes.
- Replace Action tag references with pinned commit hashes wherever possible to prevent silent tag hijacking.
- Apply the principle of least privilege to GitHub tokens and enforce hardware security keys or strong 2FA for critical accounts.
- Implement continuous secret scanning and release integrity verification (signed releases and signature checks) across repositories and artifacts.
- Harden processes around IDE extensions, plugins and third-party tools that have access to developer credentials or source code.
The Trivy supply chain attack highlights that even reputable, widely adopted security tools can become vectors for compromise. Robust software supply chain security now depends not only on code quality, but also on mature practices for access control, secret management and artifact integrity. Organizations that rely on security tooling in their CI/CD pipelines should treat these components as high-risk dependencies: verify their origin, pin versions by hash, monitor repositories for anomalies and continuously educate engineering teams on secure development and operations practices.
