The open-source vulnerability scanner Trivy has been compromised for the second time in less than a month, allowing attackers to inject malware designed to steal sensitive CI/CD secrets. The recent incident specifically targeted GitHub Actions workflows, including “aquasecurity/trivy-action” and “aquasecurity/setup-trivy,” which are crucial for scanning container images and setting up CI/CD pipelines with Trivy. This repeated compromise highlights significant supply chain security vulnerabilities that could impact numerous development environments.
Trivy Compromised Again, Stealing CI/CD Secrets
A new attack on the popular Trivy vulnerability scanner has been uncovered, exposing CI/CD secrets through malicious modifications to its GitHub Actions. Security researchers identified that an attacker managed to “force-push” 75 out of 76 version tags in the “aquasecurity/trivy-action” repository. These altered tags were then used to distribute a malicious payload, effectively turning trusted version references into a vector for an infostealer. This payload executes within GitHub Actions runners, aiming to extract valuable developer secrets such as SSH keys, cloud provider credentials, database access tokens, Git and Docker configurations, Kubernetes tokens, and cryptocurrency wallet information.
This latest incident marks the second supply chain attack involving Trivy within a short period. In late February and early March, a different autonomous bot, identified as “hackerbot-claw,” exploited a “pull_request_target” workflow. That breach resulted in the theft of a Personal Access Token (PAT), which was subsequently used to seize control of the GitHub repository. The attacker deleted several release versions and pushed two malicious versions of its Visual Studio Code (VS Code) extension to Open VSX.
The first indication of this most recent compromise came from security researcher Paul McCarty, who flagged a new compromised release, version 0.69.4, in the “aquasecurity/trivy” GitHub repository. This rogue version, which has since been removed, was found to initiate both the legitimate Trivy service and malicious code. According to Wiz, the malicious code performed two primary functions: data theft and persistence setup. It systematically scanned the system for environmental variables and credentials, encrypted this sensitive data, and then exfiltrated it via HTTP POST requests to “scan.aquasecurtiy[.]org.”
Beyond data exfiltration, the attacker also implemented persistence mechanisms. Upon detecting that the compromised version was running on a developer machine, it configured a systemd service. This service was set to execute a Python script, “sysmon.py,” which would continuously poll an external server to fetch and execute further payloads.
Itay Shakury, vice president of open source at Aqua Security, confirmed that attackers leveraged compromised credentials to publish the malicious releases of Trivy, trivy-action, and setup-trivy. In the case of “aquasecurity/trivy-action,” the adversary bypassed standard practices by force-pushing version tags to malicious commits containing the Python infostealer, rather than creating new releases or pushing to a branch. Similar actions were observed with seven “aquasecurity/setup-trivy” tags.
Philipp Burckhardt from Socket security research explained that the attacker did not need to exploit Git itself. Instead, they possessed valid credentials with sufficient privileges to push code and rewrite existing tags, enabling the observed tag poisoning. While the exact credential used in this specific step remains unclear, the root cause is understood to be a credential compromise carried over from the earlier incident.
Aqua Security acknowledged that the latest attack stemmed from incomplete containment measures following the previous “hackerbot-claw” incident. Shakury stated that while secrets and tokens were rotated, the process was not atomic, potentially exposing refreshed tokens to attackers. Consequently, Aqua Security is adopting a more restrictive approach, scrutinizing and locking down all automated actions and tokens to eliminate the threat comprehensively.
The infostealer operates through a three-stage process: first, it harvests environment variables from the runner process memory and the file system. Second, it encrypts the collected data. Finally, it exfiltrates the encrypted information to an attacker-controlled server at “scan.aquasecurtiy[.]org.”
Should the primary exfiltration attempt fail, the attacker’s fallback mechanism involves abusing the victim’s own GitHub account. Stolen data is staged in a public repository named “tpcp-docs,” utilizing a captured “INPUT_GITHUB_PAT” environment variable. This variable, commonly used in GitHub Actions for authenticating with the GitHub API, would have been obtained during the compromise.
Attribution and Mitigation Strategies
The identity of the threat actor behind this attack remains uncertain, though evidence suggests a possible link to the group known as TeamPCP. This assessment is based on the credential harvester identifying itself as “TeamPCP Cloud stealer” within its source code. TeamPCP, also known by aliases such as DeadCatx3, PCPcat, PersyPCP, ShellForce, and CipherForce, is recognized for operating as a cloud-native cybercrime platform focused on breaching cloud infrastructure for data theft and extortion.
Socket noted that the specific credential targets within the payload align with TeamPCP’s general profile of cloud-native theft and monetization. While the emphasis on Solana validator key pairs and cryptocurrency wallets is less documented as a TeamPCP hallmark, it is consistent with the group’s known financial motivations. The self-identification could potentially be a false flag, but the technical overlap with prior TeamPCP tooling makes genuine attribution plausible.
Users of Trivy and affected GitHub Actions are strongly advised to ensure they are using the latest safe releases. According to Shakury, if a user suspects they were running a compromised version, all pipeline secrets should be treated as compromised and rotated immediately. Additional mitigation steps include blocking the exfiltration domain and its associated IP address (45.148.10[.]212) at the network level. Furthermore, users should check their GitHub accounts for any repositories named “tpcp-docs,” which could indicate successful exfiltration via the fallback mechanism.
Wiz researcher Rami McCarthy recommends pinning GitHub Actions to full SHA hashes rather than version tags. This practice prevents tags from being moved to point at malicious commits, a vulnerability exploited in this recent attack. The situation remains a developing story, and further details are expected as investigations continue.