The Team PCP Snowball Effect: A Quantitative Analysis
The PCP Team’s supply chain attacks compromised two critical components of the development ecosystem: AquaSecurity’s trivy-action and the Python litellm package.
The Team PCP Snowball Effect: A Quantitative Analysis
The PCP Team’s supply chain attacks compromised two critical components of the development ecosystem: AquaSecurity’s trivy-action and the Python litellm package. These incidents affected repositories and packages across the landscape, but their true scope remains difficult to assess.
At GitGuardian, we developed and tested methodologies to evaluate this impact within the limits of publicly available data. Our analysis demonstrates how to answer concrete questions: which repositories executed malicious code during specific time windows, which packages would automatically pull compromised dependencies, and what conditions create vulnerability to such attacks. This evaluation offers a window into the cascade effects of supply chain compromise, though the complete picture extends beyond what any single organization can observe.
AquaSecurity trivy-action Compromission
The trivy-action compromise has been the first to happen and has been the source of some of the later damages. We have used GitGuardian’s dataset to list the repositories that use the trivy-action as part of their workflow definitions. To reduce the time required to later download and analyze the workflow logs, we reduced our search to repositories where workflows had been updated since January 1st, 2026. We found a total of 30,353 unique repositories.
The following analysis focuses on this sample, so that the numbers are a lower bound to the actual compromise radius.
Repositories that got compromised because of the trivy-action supply-chain attack were so by their CI/CD runs. Because a repository depends on trivy-action does not mean it got compromised. In fact, multiple conditions have to be met for this to happen:
The candidate workflow must have used a compromised version of trivy-action
The trivy-action version must have been pinned to a tag and not a commit SHA
The candidate workflow must have run during the compromise window, that is, between approximately 17:43UTC UTC on March 19, 2026, and 05:40 UTC on March 20, 2026, as per AquaSecurity’s own timeline.
To verify which repositories matched those conditions, we actively listed all candidate workflow runs, selected those that occurred during the compromise window, downloaded the workflow logs, and checked the exact commit SHA of the trivy-action action downloaded as part of the run.
[…]
2026-03-19T18:55:19.7318647Z Download action repository ‘aquasecurity/trivy-action@91e7c2c36dcad14149d8e455b960af62a2ffb275′ (SHA:91e7c2c36dcad14149d8e455b960af62a2ffb275)
[…]
Example log entry for a compromised run. SHA points to a compromised version, and execution occurs within the compromise window.
Using this methodology, we found 474 repositories that run a malicious version of trivy-action. Remember that this is from our sample of 30,000 candidate repositories, meaning the actual number of executions is likely higher. Likewise, this analysis does not account for private repositories, for which workflow logs are not publicly available.
This highlights, if needed, how such supply chain attacks can affect any entity, including high-profile companies such as Canonical, Microsoft, or NASA.
Python litellm Compromission
The litellm compromise was different from the trivy-action one in that it targeted local environments rather than CI/CD runners. Especially, while the trivy-action payload was split into two parts: a CI runner-dedicated infostealer and a more generic endpoint infostealer. The litellm package was poisoned with only the former.
From our experiment, in the general case, the litellm payload was not able to collect the most sensitive data from the CI/CD environment. Especially, it did not collect the CI secrets if those were not explicitly set as environment variables.
In the case of litellm, an interesting piece of information to collect is which Python packages, at the time of compromise, depended on litellm in such a way that installing them would have triggered the malicious payload. We tried to measure this using the following methodology:
We extracted the dependent packages from the GitHub-provided litellm dependency network.
For each of those packages, we determined the latest version at the time of compromise.
Parsing this version’s metadata, we extracted the version of litellm it required at install time.
Depending on the version qualifier, we determined if installing the package was susceptible to triggering the malware.
The information provided by GitHub in the project’s dependency graph included 2,247 unique packages. 340 of them were excluded from the rest of the analysis for various reasons:
200 did not include litellm as a dependency in their latest (at the time of the compromise) version.
51 had no published version at the time of compromise.
89 were removed from PyPi since the attack occurred.
The 1907 remaining packages were candidates for infection propagation depending on the way they included litellm as a dependency. Out of them, 202 had a strict version constraint that would have prevented the download of a malicious version:
151 pinned a precise version of the package (i.e., litellm == x.xx.x)
38 had a maximum authorized version that was below the malicious versions (i.e,. litellm <= 1.70.0)
13 had an approximate version match set to a different major branch (i.e., litellm ~= 1.72.13)
This leaves 1705 packages that were susceptible to pulling a malicious version of litellm during the time of the compromise. Part of those packages had litellm as an optional dependency: 325 of them. The 1380 other packages had litellm as a direct dependency.
The top 10 most popular packages that would have triggered a malware execution unconditionally are the following:
dspy – 5M monthly downloads
opik – 3M monthly downloads
mini-swe-agent, – 1.8M monthly downloads
crawl4ai -1.4M monthly downloads
openhands-ai – 1.2M monthly downloads
openhands-sdk – 1.2M monthly downloads
tom-swe – 1.1M monthly downloads
cua-agent – 800k monthly downloads
langchain-litellm – 700k monthly downloads
astra-assistants – 400k monthly downloads
When including packages with optional dependencies, the list includes even more popular projects:
google-cloud-aiplatform – 181M monthly downloads (extra: full)
mlflow-skinny – 34M monthly downloads (extra: genai)
mlflow – 32M monthly downloads (extra: genai)
When investigating for potential compromise, it is important to take transitive dependencies into account. To that purpose, we publish the complete list of PyPi packages from this study.
However, keep in mind this study only focused on direct dependency on litellm. The package could have been included through a longer dependency chain. Looking for the exact digest of the malicious packages is the only way to determine if the dependency was downloaded on a given machine. Moreover, doing so is paramount even if none of your corporate projects use litellm or another compromised package. One developer, or an AI agent, running an open-source tool, or a local experiment, with a malicious dependency is enough to compromise your entire corporate environment.
As a reminder, the malicious packages’ SHA256 digests are:
d2a0d5f564628773b6af7b9c11f6b86531a875bd2d186d7081ab62748a800ebb (1.82.8 wheel)
8395c3268d5c5dbae1c7c6d4bb3c318c752ba4608cfcd90eb97ffb94a910eac2 (1.82.7 wheel)
Additionally, for those who believe they have been compromised, we have outlined what steps you should immediately take in our previous blog post.
Measuring What Matters
The Team PCP incidents demonstrate that supply chain attacks generate measurable, traceable impact when analyzed with the right methodologies. Our research revealed 474 repositories executing malicious trivy-action code and 1,705 PyPI packages configured to pull compromised litellm versions, yet these numbers represent lower bounds drawn from publicly accessible data. The actual scope extends further into private repositories and transitive dependencies that are harder to quantify.
Organizations can apply these measurement techniques to their own environments, moving from uncertainty about potential exposure to concrete assessments of actual compromise. The cascade effect of supply chain attacks demands this level of precision.
*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog – Take Control of Your Secrets Security authored by Gaëtan Ferry. Read the original post at: https://blog.gitguardian.com/team-pcp-snowball-analysis/
About Author
