Trivy compromise may have triggered attack exposing more than 2,500 organizations

LiteLLM may have been only the most visible phase

The LiteLLM supply chain compromise may not have originated in the project itself. According to an analysis by SOCRadar, most of the more than 2,500 organizations associated with the incident had previously been exposed through Trivy, a tool developed by Aqua Security.

LiteLLM would therefore represent the final stage of a broader campaign attributed to the TeamPCP group. The threat actor has already been linked to attacks targeting open-source projects and the Shai-Hulud worm.

The incident was identified on August 14, 2026. However, the initial estimate of more than 2,500 organizations, also reported by CloudSEK and HudsonRock, does not represent a census of confirmed compromises. SOCRadar was able to reconstruct 2,188 entities using attributable identifiers.

The discrepancy is due to the availability of data linking each record to a specific organization. In the analyzed sample, 56% of records were classified as high confidence, 39% as medium confidence, and 6% as low confidence.

The strongest matches were based on CI host identities and legitimate committer domains. Even in these cases, however, the exposure of a credential does not automatically prove that it was used by the attacker.

From Trivy to software registries

The campaign followed a worm-like pattern. Malicious code was executed when the compromised package was downloaded and used, then searched the environment for credentials, tokens, API keys, and other secrets.

The collected data could allow the threat actor to access additional repositories or registries. Developer credentials were then reused to modify packages accessible to the attacker and publish tampered versions.

The first link observed in the chain was a malicious Trivy build. The first data collection activity was recorded on March 19 at 18:05 UTC, just 18 minutes after the compromised build was published.

Activity increased on March 22 and 23, when malicious Trivy images were available on Docker Hub. During this phase, the malware reportedly reached numerous development and continuous integration environments, collecting information from systems used to build and distribute software.

On March 24, two malicious LiteLLM versions were published. The exact version numbers were not disclosed. The packages remained available on PyPI for approximately 40 minutes before being quarantined.

That interval does not represent the full duration of the exposure. According to SOCRadar, it was only the final phase of a campaign that began with the compromise of Trivy. The last detected activity occurred on March 24 at 20:09 UTC.

For 2,085 organizations—95% of the analyzed entities—data collection had already ended before the LiteLLM packages were published. This supports the hypothesis that LiteLLM was used as the final or most visible stage, rather than as the origin of the operation.

Why the .pth payload bypassed some defenses

The tampered LiteLLM packages contained a file with a .pth extension. Python can automatically load and execute this type of file when the interpreter starts, even when the application does not directly import LiteLLM.

This behavior significantly expands the attack surface. An organization could install or launch the compromised environment without explicitly invoking the malicious component in its code.

The mechanism also enabled the malware to bypass protections based on the ignore-scripts option. This setting can prevent scripts from running during package installation, but it does not necessarily block the Python interpreter from automatically loading a .pth file.

Persistence on already infected systems added another risk factor. Even after the original package was removed, the payload could continue operating in the compromised environment.

For this reason, PyPI’s quarantine of the packages stopped the observed activity but, by itself, cannot rule out components that had already executed or credentials that had already been stolen.

CI/CD, cloud environments, and developer identities targeted

The campaign affected six continuous integration and delivery platforms:

• GitHub Actions;
• GitLab CI;
• Jenkins;
• Bitbucket;
• CircleCI;
• Buildkite.

The involvement of these environments is particularly concerning. CI/CD pipelines often have permissions to read source code, create artifacts, publish packages, and access cloud infrastructure.

The affected organizations were distributed worldwide. Germany, Brazil, and France were the countries most heavily represented in the analysis.

More than 1,000 organizations reportedly exposed JWTs and authentication tokens. Other identified data included private keys, AWS keys, GitLab tokens, OpenAI API keys, Slack webhooks, GitHub Actions tokens, and Google API keys.

The email addresses of committers were also reportedly collected from more than 1,100 organizations. Linking developer identities to tokens usable by automated processes can facilitate targeted attacks, impersonation, and further access to development systems.

Some records contained an exceptional number of secrets: the largest reportedly included approximately 3,477, while another contained about 3,459 spread across just six files. The organizations associated with these cases were not identified.

The data may already be available on criminal markets

The stolen secrets may not have remained solely on the attacker’s systems. An individual is promoting a collection on Telegram that allegedly includes data attributed to LiteLLM, Trivy, and CanisterWorm.

It is not known whether all the material came from the same phase of the campaign. The collection may have been assembled at different times, but its availability still increases the operational risk for exposed organizations.

CI/CD tokens, cloud keys, and developer credentials can be used to access repositories, modify pipelines, publish additional malicious packages, or reach external services. API keys can also generate costs, provide access to data, or be abused in automated activity.

The combination of automated propagation and credential reuse explains why the incident should not be considered limited to LiteLLM. A single compromised package can become an entry point into a network of projects, pipelines, and software registries.

What exposed organizations should check

The only documented containment measure is PyPI’s quarantine of the malicious LiteLLM packages. No specific patches, fixed versions, official cleanup procedures, or complete list of technical indicators have been disclosed.

Organizations that used Trivy or LiteLLM in the affected environments should review their CI/CD pipelines, repositories, and systems for unexpected .pth files. They should also treat any identified secrets as potentially compromised until independently validated.

Simply removing the package is not enough to rule out persistence. Organizations should also inspect hosts where the code may have executed and investigate subsequent publications, repository changes, or anomalous access.

The brief does not include official remediation instructions from the vendors, nor does it confirm whether the vulnerability or campaign was added to CISA’s KEV catalog. As a result, no catalog entry date or CISA deadline is currently available.

The operational priority remains revoking and replacing potentially exposed credentials, together with reviewing pipeline permissions. Without complete confirmation that the secrets were used, a cautious approach is to treat them as compromised.