Vigilant Research

Software Supply Chain Attack Escalation: Trivy, LiteLLM, and the 50K-Repo Vulnerability Landscape

March 25, 2026  |  Threat Level: CRITICAL

Over the past three weeks, a threat actor known as TeamPCP has executed a cascading software supply chain attack that represents the most significant CI/CD threat tracked to date. What began as a single compromised GitHub Action has escalated into a multi-hop campaign that has now reached the AI infrastructure layer, compromising the package that manages LLM API keys for organizations worldwide.

This is not theoretical. Three confirmed attacks in three weeks, each using the previous compromise as a stepping stone:

• March 12 - tj-actions/changed-files: Attackers compromised a widely-used GitHub Action, injecting code that stole secrets from thousands of CI/CD pipelines
• March 19 - Aqua Security Trivy: The same attackers compromised Trivy, one of the most widely-used open-source vulnerability scanners. The tool designed to find security issues became the attack vector
• March 24 - BerriAI LiteLLM: LiteLLM, the most popular AI API key management gateway (97 million monthly downloads), was backdoored via its own CI/CD pipeline, which ran the compromised Trivy scanner. Every organization that updated to version 1.82.7 or 1.82.8 had all environment variables, SSH keys, cloud credentials, and AI API keys exfiltrated to an attacker-controlled server

Vigilant anticipated this escalation pattern. Three weeks ago, we completed the largest CI/CD security scan ever conducted, scanning the 50,000 most-starred repositories on GitHub. We found that 20,265 repositories (40.6%) have the same class of vulnerability that enabled this attack chain. The full research is published at vigilantdefense.com/research.

How the LiteLLM Attack Worked

This attack is a textbook example of a multi-hop supply chain compromise. Each step was deliberate and calculated:

1. Attackers compromised Aqua Security's Trivy vulnerability scanner through its GitHub Action
2. LiteLLM's CI/CD pipeline ran Trivy as part of its build process, pulled without a pinned version
3. The compromised Trivy exfiltrated LiteLLM's PyPI publish token from the CI/CD runner
4. Attackers used the stolen token to push malicious LiteLLM versions (1.82.7, 1.82.8) to PyPI
5. A hidden .pth file executes automatically when Python starts. No import needed. Just having the package installed is enough
6. The payload harvested all environment variables, SSH keys, cloud credentials, and AI API keys, then sent everything to attacker infrastructure

Why This Matters to Your Organization

LiteLLM is not an obscure library. It is the most widely used AI API gateway, with 97 million monthly downloads. It is specifically designed to hold and manage API keys for OpenAI, Anthropic, Azure, AWS Bedrock, and every other major LLM provider. The attacker deliberately targeted the one package that, by definition, has access to every AI API key in an organization.

If your organization uses LiteLLM, or uses any software that depends on LiteLLM as a transitive dependency, you may be affected. The malicious payload was discovered when an MCP plugin running inside a code editor pulled the compromised package as a transitive dependency, meaning developers who never directly installed LiteLLM were still exposed.

Vigilant's Research: We Found This Pattern Before the Attack

After the tj-actions attack in early March, Vigilant built and open-sourced Runner Guard, a free CI/CD security scanner, and conducted the largest scan of its kind, examining the 50,000 most-starred repositories on GitHub for the exact vulnerability classes that enabled this attack chain.

Our scan of the LiteLLM repository specifically found 135 CI/CD vulnerabilities across 6 rule categories before this attack occurred. Across the broader dataset of 50,000 repositories, we found 192,776 CI/CD vulnerabilities affecting 20,265 repositories, with 590 million downstream forks inheriting these vulnerable configurations.

The most popular, most trusted projects are the most exposed. Repositories with 50,000+ stars have a 68% vulnerability rate. Vigilant is the first and only organization to conduct research at this scale. The full findings are published at vigilantdefense.com/research.

Recommended Actions

Immediate: Next 24 Hours

1. Check for LiteLLM exposure. Determine if any system, application, or developer machine in your environment has LiteLLM installed. Check both direct installations and transitive dependencies. If versions 1.82.7 or 1.82.8 are present, assume all credentials on that machine have been compromised.
2. Rotate all AI API keys and cloud credentials. If LiteLLM was present in any form, rotate every API key, cloud credential, and SSH key on the affected systems. This includes OpenAI, Anthropic, Azure, AWS, and any other service credentials that were accessible as environment variables.
3. Freeze all open-source package updates. Do not update any open-source dependency until it has been verified as safe. This applies to pip, npm, go modules, and any other package manager. The supply chain is actively under attack. Treat every update as potentially hostile until verified.
4. Review CI/CD pipeline dependencies. Identify every third-party tool, action, or scanner that runs in your build pipelines. If any are pulled without version pinning or integrity verification, they are a potential entry point for this same attack pattern.

Near-Term: Next 7 Days

5. Scan your repositories with Runner Guard. Vigilant's open-source CI/CD scanner detects the exact vulnerability classes exploited in this attack chain. It is free, takes one command to run, and covers 15 security rule categories including supply chain trust, injection, privilege escalation, and AI agent configuration risks.

6. Scan any third-party open-source project before adoption or update. Clone the repository locally and run Runner Guard against it before integrating it into your environment. If it has unpinned dependencies, overly permissive tokens, or injection vulnerabilities in its CI/CD pipeline, those are the exact entry points attackers are exploiting right now.
7. Implement version pinning. Every GitHub Action, every package dependency, and every tool in your CI/CD pipeline should be pinned to an immutable hash, not a mutable version tag. Tags like @v3 or @latest can be silently redirected to malicious code. SHA pinning is the only reliable defense.
8. Establish an update verification process. No open-source package should be updated in production environments without first verifying the new version against known-good checksums, reviewing the changelog for unexpected changes, and scanning the project's CI/CD configuration for vulnerabilities.

Supply Chain Security Best Practices

• Do not update any open-source package today without scanning it first. The supply chain is actively compromised. Treat every update as suspicious until verified.
• Be careful what you install. Transitive dependencies are attack vectors. LiteLLM was pulled as a dependency of other packages. Developers who never directly installed it were still compromised.
• Pin everything. Mutable version tags are the root cause of this entire attack chain. SHA pinning for GitHub Actions. Lock files with integrity hashes for package managers. No exceptions.
• Apply least-privilege to CI/CD tokens. If LiteLLM's PyPI publish token had been scoped to only run during tagged releases with manual approval, the attacker could not have pushed a malicious version from a compromised build step.
• Monitor for anomalous package behavior. The LiteLLM compromise was discovered because a developer's machine ran out of RAM from a fork bomb in the payload. Not every compromise will be that obvious. Monitor for unexpected network connections, environment variable access, and file system changes from your dependencies.

Sources: The Register, The Hacker News, Wiz Security Blog, Snyk Security Research, ARMO Security, GitHub Advisory Database, Vigilant 50K Scan Research.