LiteLLM supply chain attack: What happened and what to do

You check the security news on a Tuesday morning and see that Trivy, one of the most trusted open-source scanners in the ecosystem, has been compromised. Your first question isn’t “how did it happen.” Your first question is “are we affected?”

The answer to that first question shouldn’t take half a day. In this article, we’ll walk through the attack chain from Trivy to LiteLLM, why AI tooling made the damage worse, and how we checked our own exposure in minutes.

What happened: Trivy to LiteLLM in five days

A security scanner turned into a credential-stealing weapon this week. And the fallout reached AI tooling within days.

A threat group called TeamPCP broke into Trivy’s GitHub Actions automation and force-pushed 75 of 76 version tags. Trivy is one of the most widely used open-source vulnerability scanners, so the impact was immediate. Every CI/CD pipeline running Trivy through GitHub Actions (over 10,000 workflows, according to Socket) was now executing a malicious payload instead of a security scan.

The payload targeted everything worth stealing: SSH keys, AWS credentials, Kubernetes configs, CI/CD tokens, .env files, and API keys. Attackers then used those stolen credentials to cascade across ecosystems, hitting npm packages and Checkmarx KICS along the way.

The biggest downstream hit landed on LiteLLM, a Python library that acts as a universal API wrapper for large language models. Using a PyPI publishing token stolen from LiteLLM’s own Trivy-powered CI pipeline, the attackers pushed two backdoored versions (1.82.7 and 1.82.8) directly to PyPI. The malicious code harvested credentials, deployed privileged pods for lateral movement inside Kubernetes clusters, and installed persistent backdoors via systemd.

PyPI quarantined the package within hours. But at LiteLLM’s download scale, thousands of environments likely pulled the compromised versions before the takedown.

One compromised tool, five days, and a chain reaction across the open-source ecosystem. And the blast radius got worse because of where LiteLLM sits in the AI stack.

Why AI tooling made the blast radius worse

LiteLLM isn’t a niche library. It sits inside AI agent frameworks like DSPy and CrewAI, MCP servers, and internal AI tools across tens of millions of monthly downloads.

Many organizations still treat AI tooling as experimental. Looser security controls, fewer reviews, faster approvals. But these libraries often run with access to cloud credentials, Kubernetes clusters, and sensitive APIs. They’re high-value targets wearing a “sandbox project” label.

So the practical guidance here is straightforward. Don’t plug in tools or services that haven’t gone through your security review process. Before adding a library, take a few minutes to understand what it actually does and what permissions it needs. Avoid connecting random external tools (think OpenClaw and similar) without vetting them first. And stick to best practices around CI/CD and dependency management: pin your versions, verify your sources, review your pipeline permissions.

And one concrete step you can take today: pin your dependencies to exact versions and commit SHAs, not floating tags. The Trivy compromise worked precisely because pipelines pulled the latest version that the attackers had force-pushed. A pinned SHA wouldn’t have resolved to the malicious payload.

TeamPCP claims to hold a 300GB trove of stolen credentials from the campaign. Even if that number is exaggerated, the volume of secrets extracted from 10,000+ CI/CD workflows almost guarantees more downstream compromises are coming. LiteLLM probably won’t be the last.

Checking your own exposure is the next logical step, and it doesn’t have to take long.

How we checked our exposure in 3 minutes

When the news broke, our team needed a fast answer: are any of our repos pulling compromised LiteLLM versions? Instead of manually auditing pipelines and dependency files, we opened Sola and typed one prompt:

Sola ran a scan across three data sources simultaneously: Vulnerability Alerts (repo and org level), Dependabot Alerts (repo and org level), and SBOM (Software Bill of Materials). Within about three minutes, we had a structured response:

• Clear verdict: Repositories are not affected. One repo uses LiteLLM at v1.80.0, safely below the compromised range.
• Threat context: Sola explained what the backdoor does, including credential exfiltration via a malicious .pth file and persistent C2 through systemd. Even though we weren’t affected, the team got full threat detail for awareness.
• Bonus flag: v1.80.0 is outdated and carries its own known vulnerabilities (SSRF, authorization flaws). Sola recommended upgrading to a clean version while skipping 1.82.7 and 1.82.8 entirely.
• Next steps: Set up an alert rule to catch vulnerable LiteLLM versions in SBOM going forward, or export findings as a report.

The analysis generated 3 reusable SQL queries, now saved in the Query Library for the team. Incident response to a supply chain attack became a single prompt, not a half-day investigation.

Check your own stack

The Trivy-to-LiteLLM chain is unlikely to be an isolated incident. With a massive volume of stolen credentials still in play, we expect more third-party packages will get compromised in the weeks ahead. The question for your team isn’t whether the next supply chain attack will happen. It’s whether you’ll catch it in minutes or find out days later.

If you want to check your own exposure right now, you can ask Sola the same question we did. One prompt, three data sources scanned, a structured answer with next steps.

Key Takeaways

• AI tooling often runs with production-level permissions (cloud credentials, Kubernetes clusters, sensitive APIs) while getting treated as experimental. Fewer security controls on these libraries means a bigger blast radius when one gets compromised.
• Supply chain attacks cascade fast. Trivy to LiteLLM took five days, and the same stolen credential pool likely hit other packages. Check your dependency chain before the next disclosure, not in response to it.
• Pin dependencies to exact versions and commit SHAs, verify your sources, and review CI/CD pipeline permissions. Run every library through the same security review process you’d apply to production infrastructure.
• Exposure checks don’t need a half-day investigation. With Sola, scanning repos against a specific compromised version range across SBOM, Dependabot, and vulnerability alert data takes a single prompt and about three minutes.