Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked to Steal CI/CD Secrets

This latest incident specifically targeted the GitHub Actions workflows "aquasecurity/trivy-action" and "aquasecurity/setup-trivy." These actions are instrumental for developers and organizations leveraging GitHub’s CI/CD capabilities to automate the scanning of Docker container images for vulnerabilities and to integrate specific versions of the Trivy scanner into their build processes. The compromise underscores the escalating threat landscape surrounding software supply chains, where seemingly innocuous development tools can become conduits for sophisticated attacks.

Sophisticated Attack Vector: Tag Poisoning in GitHub Actions

According to Philipp Burckhardt, a security researcher at Socket, the attackers employed a highly stealthy and effective method known as "tag poisoning." They "force-pushed 75 out of 76 version tags in the aquasecurity/trivy-action repository," which serves as the official GitHub Action for integrating Trivy vulnerability scans into CI/CD pipelines. This aggressive maneuver effectively rewrote the history of these tags, redirecting what were previously trusted version references to now point to malicious commits. The result was a distribution mechanism for an infostealer payload, covertly embedded within widely used and seemingly legitimate versions of the scanner. A similar tactic was observed with "aquasecurity/setup-trivy," where seven tags were similarly force-pushed.

The payload, once executed within GitHub Actions runners, initiates a highly targeted exfiltration process. Its primary objective is to harvest a comprehensive array of high-value developer secrets from the compromised CI/CD environments. This includes, but is not limited to, SSH keys crucial for secure remote access, credentials for various cloud service providers (such as AWS, Azure, Google Cloud), database access credentials, Git repository access tokens, Docker configuration files, Kubernetes tokens vital for cluster management, and even cryptocurrency wallet keys. The potential impact of such a breach is catastrophic, enabling attackers to gain deep access into an organization’s infrastructure, intellectual property, and financial assets.

A Recurring Nightmare: Second Supply Chain Breach for Trivy

This current incident is not an isolated event but rather the second major supply chain compromise involving Trivy within a remarkably short period. The preceding breach occurred between late February and early March 2024, highlighting a persistent vulnerability that attackers have repeatedly exploited. In that earlier attack, an autonomous bot, dubbed "hackerbot-claw," exploited a weakness in a "pull_request_target" workflow. This specific GitHub Actions workflow configuration, when misconfigured, can grant excessive permissions to pull requests from forks, allowing malicious code to run with elevated privileges.

The hackerbot-claw managed to steal a Personal Access Token (PAT), a highly sensitive credential often used for programmatic access to GitHub. This stolen PAT was subsequently weaponized by the attackers to seize unauthorized control of the GitHub repository. With this control, they proceeded to delete several legitimate release versions of Trivy and, more critically, pushed two malicious versions of its Visual Studio Code (VS Code) extension to Open VSX, a marketplace for open-source VS Code extensions. This initial attack demonstrated a sophisticated understanding of CI/CD pipeline vulnerabilities and the potential to leverage compromised credentials for widespread malicious distribution.

The first public indication of the initial compromise came from security researcher Paul McCarty, who flagged a new, compromised release (version 0.69.4) published to the "aquasecurity/trivy" GitHub repository. While this rogue version was swiftly identified and removed, analysis by security firm Wiz revealed that version 0.69.4 was designed to simultaneously run the legitimate Trivy service alongside the malicious code. This dual-purpose execution is a common tactic to evade detection, as the primary function of the tool continues to operate as expected, masking the underlying nefarious activity.

Incomplete Containment: The Root Cause of the Second Attack

In an official statement released on GitHub, Itay Shakury, Vice President of Open Source at Aqua Security, confirmed that the latest attack was a direct consequence of compromised credentials. He elaborated that attackers leveraged a previously compromised credential to publish malicious releases across Trivy, trivy-action, and setup-trivy. Shakury’s candid admission revealed that the "aquasecurity/trivy-action" repository saw 75 version tags force-pushed to malicious commits containing the Python infostealer payload. This was done without the creation of new releases or pushes to a standard branch, which are typical development practices and often trigger automated security checks. A similar compromise affected seven tags in the "aquasecurity/setup-trivy" repository.

Philipp Burckhardt further clarified the attack mechanism, explaining that the attackers did not need to exploit Git itself. Instead, they possessed valid credentials with sufficient privileges to push code and rewrite tags, which is the foundational capability that enabled the observed tag poisoning. The precise nature of the compromised credential (e.g., a maintainer’s Personal Access Token or an automation token) remains subject to internal investigation, but the overarching root cause is now understood to be a credential compromise carried over from the earlier hackerbot-claw incident. This highlights a critical lesson in incident response: the thoroughness of containment measures is paramount. Aqua Security itself acknowledged that the latest attack stemmed from an "incomplete containment" of the initial hackerbot-claw incident. Shakury noted that while secrets and tokens were rotated, the process was not "atomic," implying a window of opportunity during which attackers may have gained access to the refreshed tokens before the old ones were fully invalidated or new ones secured. In response, Aqua Security has announced a more stringent approach, locking down all automated actions and tokens to definitively mitigate the problem.

The Infostealer’s Modus Operandi

The malicious infostealer payload operates in a carefully orchestrated three-stage process to maximize its effectiveness and stealth:

1. Harvesting: The initial stage involves aggressively collecting environment variables from the GitHub Actions runner process memory and its file system. This cast-net approach aims to capture any sensitive information that might be present in the execution environment, including API keys, database connection strings, and other configuration data.
2. Encryption: Once harvested, the stolen data is immediately encrypted. This step serves two purposes: to obscure the data from casual inspection if it were to be discovered locally, and to prepare it for secure (from the attacker’s perspective) exfiltration.
3. Exfiltration: The final stage involves transmitting the encrypted data to an attacker-controlled command-and-control (C2) server, specifically identified as "scan.aquasecurtiy[.]org." This domain, deceptively similar to Aqua Security’s legitimate branding, aims to blend in with legitimate network traffic and avoid detection.

In a scenario where the primary exfiltration attempt to the C2 server fails, the infostealer has a sophisticated fallback mechanism. It abuses the victim’s own GitHub account, leveraging the captured INPUT_GITHUB_PAT environment variable – which typically passes a GitHub Personal Access Token for authentication with the GitHub API – to stage the stolen data in a public repository. This repository is specifically named "tpcp-docs," an identifier that has proven crucial in attributing the attack. This method ensures data exfiltration even if the C2 server is blocked or unreachable, highlighting the attackers’ persistence and robust design.

Attribution and the Shadow of TeamPCP

While definitive attribution in cyberattacks is often challenging, strong indicators suggest the notorious threat actor group known as TeamPCP may be behind this sophisticated campaign. The primary piece of evidence comes directly from the credential harvester’s source code, which explicitly self-identifies as "TeamPCP Cloud stealer." This self-labeling, while potentially a false flag, gains credibility when considering the group’s established methodologies.

TeamPCP, also recognized by various aliases such as DeadCatx3, PCPcat, PersyPCP, ShellForce, and CipherForce, is a well-documented cloud-native cybercrime platform. Their modus operandi revolves around breaching modern cloud infrastructure to facilitate data theft and extortion. Elastic Security Labs has previously detailed TeamPCP’s focus on exploiting cloud environments.

Socket’s analysis further reinforces this potential attribution, noting that the types of credentials targeted by this payload are highly consistent with TeamPCP’s broader profile of cloud-native theft and monetization. While the heavy emphasis on Solana validator key pairs and general cryptocurrency wallets is less extensively documented as a hallmark of TeamPCP, it aligns perfectly with the group’s known financial motivations. Despite the possibility of a false flag, the significant technical overlap with previous TeamPCP tooling makes a genuine attribution highly plausible, painting a picture of a well-resourced and persistent threat actor.

Broader Implications for Software Supply Chain Security

The dual compromise of Trivy serves as a stark reminder of the escalating risks associated with software supply chain attacks. As development increasingly relies on open-source components and automated CI/CD pipelines, these environments become prime targets for adversaries seeking to inject malicious code at an early stage. A compromise within a widely used tool like Trivy, which is designed to enhance security, can have a cascading effect across countless organizations that integrate it into their workflows.

The incident highlights several critical vulnerabilities inherent in modern software development:

• Trust in Open Source: While open-source software fosters innovation, the sheer volume and complexity of dependencies make it challenging to verify the integrity of every component.
• CI/CD Pipeline Security: CI/CD environments, by design, require access to highly privileged credentials to automate tasks. Securing these pipelines against credential theft and unauthorized code injection is paramount but often overlooked.
• Incident Response Gaps: The incomplete containment of the first incident demonstrates the difficulty of fully eradicating sophisticated threats, especially when attack vectors involve compromised credentials and subtle manipulation of version control systems.
• Advanced Persistent Threats: Groups like TeamPCP exemplify the growing sophistication of cybercriminals who understand the intricacies of cloud-native development and are adept at exploiting subtle weaknesses.

The impact extends beyond immediate data theft. Such breaches erode trust in essential security tools and the broader open-source ecosystem, potentially leading to increased scrutiny, slower adoption of beneficial technologies, and a diversion of critical resources towards remediation rather than innovation.

Mitigation and Recommendations for Users

In light of these critical compromises, immediate action is advised for all users of Trivy and related GitHub Actions. Aqua Security, alongside security researchers, has issued urgent recommendations:

1. Update to Safe Releases: Users must ensure they are running the absolute latest safe releases of Trivy and its associated GitHub Actions. This typically means updating to versions explicitly designated as clean by Aqua Security.
2. Immediate Secret Rotation: If there is any suspicion of having run a compromised version, all pipeline secrets must be treated as compromised and rotated without delay. This includes, but is not limited to, GitHub Personal Access Tokens (PATs), cloud provider credentials, database passwords, and any other sensitive keys used within CI/CD workflows.
3. Network-Level Blocking: Organizations should implement network-level blocks for the exfiltration domain "scan.aquasecurtiy[.]org" and its associated IP address (45.148.10[.]212). This can prevent any ongoing or future attempts at data exfiltration.
4. Repository Audit: A thorough check of GitHub accounts for any newly created or modified public repositories named "tpcp-docs" is crucial. The presence of such a repository may indicate successful data exfiltration via the attacker’s fallback mechanism.
5. Pin GitHub Actions to Full SHA Hashes: As emphasized by Wiz researcher Rami McCarthy, a fundamental security practice is to pin GitHub Actions to full SHA hashes rather than mutable version tags (e.g., v1, main, or 0.69.4). Version tags can be retrospectively moved to point at malicious commits, as vividly demonstrated in this attack. Pinning to an immutable SHA hash guarantees that the exact, verified code is always executed, preventing such tag poisoning exploits.
6. Enhanced Monitoring: Implement robust logging and monitoring for all CI/CD pipeline activities, paying close attention to unusual GitHub API calls, unexpected repository creations, or anomalous network traffic originating from build runners.
7. Least Privilege Principle: Review and enforce the principle of least privilege for all tokens and credentials used within CI/CD pipelines. Grant only the minimum necessary permissions for tasks to be completed.
8. Multi-Factor Authentication (MFA): Ensure MFA is enabled for all GitHub accounts, especially those with administrative privileges over repositories.

The ongoing nature of these attacks against a foundational open-source security tool underscores the constant vigilance required in the cybersecurity landscape. Organizations must not only react to breaches but proactively implement comprehensive security measures across their entire software development lifecycle, recognizing that the integrity of their supply chain is as critical as the security of their deployed applications.