Millions of automated software development pipelines rely on security tools — such as Trivy and Checkmarx AST — integrated into the build process. And it was namely these trusted solutions that recently became the entry point for one of the largest and most dangerous supply chain attacks in modern history. In this post we discuss how to audit automated workflows and secure corporate cloud infrastructure.
On March 19, a successful targeted supply chain attack was carried out via Trivy, an open-source vulnerability scanning tool widely used in CI/CD pipelines. The attackers — a group known as TeamPCP — managed to inject malware into official GitHub Actions workflows and Docker images associated with Trivy. As a result, every automated pipeline scan made triggered malware that stole SSH keys, cloud access tokens, cryptocurrency wallets, and other valuable data from compromised systems. Given the critical nature of the incident, it was assigned the identifier CVE-2026-33634, with a near-maximum CVSS4B score of 9.4.
Later that same day, the Trivy team detected the attack and removed malicious artifacts from the distribution channels, halting this phase of the attack. However, the attackers had already gained access to the environments of many Trivy users.
On March 23, a similar incident was discovered in another application security tool: a GitHub Action for Checkmarx KICS, as well as Checkmarx AST. Three hours later, the malicious code was removed from there as well. TeamPCP also managed to compromise OpenVSX extensions supported by Checkmarx: cx-dev-assist 1.7.0 and ast-results. Reports on when this part of the incident was resolved vary.
On March 24, a popular project using Trivy’s code scanning — the LiteLLM AI gateway, a universal library for access to various LLM providers — was attacked. Versions 1.82.7 and 1.82.8, uploaded to PyPI repository, were compromised. These versions were publicly available for about five hours.
But the fact that the attack lasted only a few hours is no reason to dismiss it. Given the popularity of the affected projects, the malicious code could have been executed thousands of times — including within the infrastructure of very large companies.
This allowed attackers to deploy persistent backdoors in Kubernetes clusters, as well as launch the self-replicating CanisterWorm across the JavaScript npm ecosystem.
The attackers’ code has destructive capabilities that wipe out a Kubernetes cluster and all its nodes if it detects either Tehran’s time zone, or Farsi as the primary language on the compromised system. In other regions, the malware simply steals data using CanisterWorm.
According to experts, more than 20,000 repositories are considered potentially vulnerable. The attackers claim to have stolen hundreds of gigabytes of data and more than half a million accounts.
To compromise Trivy, the attackers used credentials stolen in a previous incident. The previous Trivy compromise, which occurred in late February, was likely not fully contained, and the attackers — the same TeamPCP group — returned with a new attack. Trivy’s developers, Aqua Security, speculate that because credentials were being phased out gradually following the previous incident, the attackers were able to generate new access tokens for themselves before compromised old ones had been revoked.
As a result, TeamPCP was able to compromise GitHub Actions used in CI/CD pipelines. Using credentials with tag-writing privileges, the attackers forcibly overrode 76 out of 77 version tags in aquasecurity/trivy-action, and all seven tags in aquasecurity/setup-trivy, redirecting existing trusted versions to malicious commits. This resembles tactics observed in the Shai-Hulud 2.0 campaign. As a result, workflows throughout the pipeline began executing the attackers’ code, while the release metadata showed no visible changes.
At the same time, the attackers published an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries.
The compromise of the popular language-model access tool LiteLLM could itself trigger a major wave of attacks across the chain of projects that use it. The attack took place on March 24, 2026, when TeamPCP directly published malicious versions of the library (1.82.7 and 1.82.8) on PyPI. Between 10:39 UTC and 16:00 UTC, these compromised packages contained malware that stole credentials. It was embedded in the proxy_server.py file, and version 1.82.8 also contained a malicious litellm_init file. The stolen data was exfiltrated to the server models.litellm[.]cloud.
Customers using LiteLLM Cloud or the official LiteLLM Proxy Docker image were not affected due to strict version locking, whereas developers and downstream projects that installed unpinned versions via pip during the specified time window were compromised.
Within three hours, the malicious packages were removed from the PyPI repository, and the LiteLLM team suspended new releases, rotated credentials, and engaged an external incident response process. Teams that use LiteLLM in their projects are advised to immediately check for the litellm_init.pth compromise indicator, and routinely rotate all potentially compromised secrets.
Attackers added new logic to GitHub Actions and the Trivy executable while preserving the original functionality. Vulnerability scan results via Trivy appeared normal, but at the same time valuable data was being searched for and extracted. Malicious code was doing the following:
The collected data was encrypted and uploaded to a server with a name similar to the that of the Trivy’s developers (scan.aquasecurtiy[.]org). As a backup mechanism, the attackers provided a method for uploading data to a repository named docs-tpcp.
The attack on CheckMarx and LiteLLM used a similar tactic with other typosquatting domains: models.litellm[.]cloud and checkmarx[.]zone.
A detailed technical analysis of the malware, along with indicators of compromise, can be found in our expert’s article on the Securelist blog.
Existing signature-based checks and dependency scanning in public registries are no longer sufficient, as the malicious code was injected directly into trusted, signed actions, and evaded detection until behavioral monitoring was applied. CI/CD pipelines have become the “new perimeter” of security.
Immediate Actions. Ensure that all workflows use secure versions (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).
CI/CD pipeline administrators and security teams should immediately review their dependances to Checkmarx (kics-github-action, ast-github-action) and Trivy (setup-trivy and trivy-action) solutions. If workflows referenced a version tag rather than a specific SHA hash, carefully review your workflow execution logs for the duration of the active supply chain attack.
You should also check your network logs for traffic to the domains scan.aquasecurtiy[.]org, checkmarx[.]zone, and models.litellm[.]cloud. The presence of such traffic indicates that sensitive data has been successfully exfiltrated.
If a repository named docs-tpcp has appeared on organization’s GitHub, this may also indicate a successful data breach.
In any case, a proactive threat hunt should be conducted, assuming that the systems have been successfully compromised and that the attackers have rapidly advanced within the affected systems.
It’s recommended to restore the affected environments from verified backups.
Check hosts and clusters for signs of compromise – the presence of ~/.config/sysmon/sysmon.py files, suspicious pods in Kubernetes.
Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions.
Dependency pinning and secret management. Ensure that exact dependency versions are pinned using cryptographic hashes in all pipelines and Dockerfiles. We advise transitioning from long-lived tokens to short-lived credentials by using a secrets manager tool, and implementing OIDC integrations where supported. Minimize the injection of secrets into the runtime environment — do so only when it’s absolutely necessary. Ensure that secrets are not stored on disk or in temporary files, and are not reused across different processes.
Rotate all potentially compromised credentials – API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets.
Other security measures. Allow only GitHub Actions from a list approved by the organization; block new and unverified processes. Configure GITHUB_TOKEN and other access keys in accordance with the principle of least privilege. Don’t grant write permissions unless absolutely necessary.
To enhance the security of GitHub Actions, there are several open-source tools available:
If you want to learn more about supply chain attacks, we invite you to look at our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts, and reveals how often organizations face supply chain and trusted relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against these kinds of threats.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。