Your LLM Proxy Was Backdoored for 5 Hours. Here Is What to Do Now.

The Library That Holds All Your API Keys Got Compromised

On March 24, 2026, somebody published backdoored versions of LiteLLM to PyPI. Versions 1.82.7 and 1.82.8 contained a multi-stage credential stealer that harvested API keys, SSH keys, AWS/GCP/Azure credentials, Kubernetes tokens, database connection strings, and cryptocurrency wallets. The malicious packages were live on PyPI for roughly 5 hours before being quarantined.

LiteLLM is not some obscure library. It is the most popular open-source LLM proxy, with 95 million monthly downloads and integrations across virtually every major AI agent framework. If your team runs any LLM-powered application in production, there is a good chance LiteLLM is somewhere in your dependency tree.

The attack was not a typosquat or a rogue maintainer. A threat actor group called TeamPCP compromised LiteLLM's own CI/CD pipeline by first backdooring Aqua Security's Trivy vulnerability scanner, then using the stolen credentials to publish malicious packages directly to PyPI. Your security scanner was the entry point.

How the Attack Worked

The attack chain had three stages, and each one should make you uncomfortable:

Stage 1: Compromise the security tool. On March 19, TeamPCP injected credential-stealing malware into Trivy's GitHub Actions and official releases. Trivy is used by thousands of CI/CD pipelines to scan for vulnerabilities. The malicious version dumped Runner.Worker process memory, searched for {"value":"<secret>","isSecret":true} patterns, and exfiltrated everything it found.

Stage 2: Harvest CI/CD secrets. Every CI pipeline that ran the compromised Trivy action leaked its secrets. LiteLLM's pipeline was one of them. The attackers got PyPI publish tokens.

Stage 3: Publish backdoored packages. Using the stolen tokens, TeamPCP published LiteLLM 1.82.7 and 1.82.8. Version 1.82.8 was particularly nasty: it included a .pth file (litellm_init.pth) that executes automatically on every Python process startup, no import required. Just having the package installed was enough. Every pip install, every IDE language server startup, every python -c command triggered the stealer.

The stolen data was encrypted with AES-256 and an RSA-4096 wrapped session key before exfiltration. Professional-grade malware targeting the AI development supply chain.

Check If You Were Exposed

If any of these are true, you need to investigate:

# Check if you installed the affected versions
pip show litellm | grep Version
# Affected: 1.82.7 or 1.82.8
 
# Check pip install logs for the time window
# Affected window: March 24, 2026, 10:39 UTC to ~16:00 UTC
 
# Check your lockfile history
git log --oneline -20 -- requirements.txt Pipfile.lock poetry.lock
 
# Search Docker image layers for the bad versions
docker history your-image:latest | grep litellm

If you ran pip install litellm or pip install --upgrade litellm on March 24 between those hours, assume your environment variables, API keys, cloud credentials, and SSH keys were exfiltrated. Rotate everything.

Five Things to Do Right Now

These are not theoretical best practices. These are the specific steps that would have prevented or limited the impact of this exact attack.

1. Pin dependencies with hashes, not just versions.

Version pinning (litellm==1.82.6) would not have saved you here. The attacker published a new version number. Hash pinning catches it because the hash of the legitimate package differs from the backdoored one.

# requirements.txt with hash pinning
litellm==1.82.6 \
    --hash=sha256:abc123...your_known_good_hash_here

Run pip install --require-hashes -r requirements.txt and pip will refuse to install any package whose hash does not match. This is an all-or-nothing mode: if you specify a hash for one package, you need hashes for all of them. Use pip-compile --generate-hashes from pip-tools to automate it.

2. Pin your CI/CD actions to commit SHAs, not tags.

The Trivy compromise worked because pipelines referenced aquasecurity/trivy-action@latest or a mutable tag. Tags can be force-pushed. Commit SHAs cannot.

# Bad: mutable tag
- uses: aquasecurity/trivy-action@master
 
# Good: pinned to immutable commit SHA
- uses: aquasecurity/trivy-action@a7a829a # v0.18.0

GitHub's Dependabot can auto-update pinned SHAs when new releases are available, so you do not lose the convenience of automatic updates.

3. Isolate your PyPI publish tokens.

LiteLLM's PyPI token was accessible to the CI runner that also ran Trivy. If the publish token had been in a separate, restricted environment that Trivy could not reach, the attacker would have had Trivy access but no path to PyPI.

In GitHub Actions, use environment-level secrets with required reviewers for your publish workflow. The security scanning job should never have access to the publishing secrets.

4. Run a Software Bill of Materials (SBOM) for your AI stack.

An AI-BOM goes beyond traditional SBOMs. It covers Python packages, model artifacts, training data provenance, and inference dependencies. The NSA/CISA guidance on AI/ML supply chain risks published March 4, 2026 specifically calls this out: you need to know what is in your AI pipeline before you can defend it.

# Generate SBOM with syft (not Trivy, for obvious reasons right now)
syft dir:/path/to/your/ml-project -o spdx-json > ai-sbom.json

5. Monitor for unexpected network calls from your ML environment.

The LiteLLM stealer exfiltrated data to an external server. If your ML training or inference environment is making HTTP calls to domains not on your allowlist, that is a signal. Network segmentation for ML workloads is not paranoia anymore. It is baseline hygiene.

The Bigger Problem Nobody Wants to Talk About

Research from Mitiga analyzing 10,000 open-source ML projects found that 68.4% have unpinned third-party GitHub Actions, making them sitting ducks for exactly this type of attack. The AI/ML ecosystem has imported all the bad habits of traditional software development and added new attack surfaces on top: model files that execute arbitrary code on load, training data that can be poisoned, and inference pipelines that run with access to production databases.

The TeamPCP campaign did not stop at Trivy and LiteLLM. They also compromised Checkmarx's GitHub Action using the same technique, four days later. Security tools being the attack vector is not a one-off. It is a pattern.

Where Your ML Pipeline Is Probably Vulnerable

If you are running ML workloads in production, here is a quick self-assessment:

• Do your requirements files use hash pinning? (Most do not.)
• Are your GitHub Actions pinned to SHAs? (Most are not.)
• Can your CI security scanner access your publish tokens? (It probably can.)
• Do you know every Python package in your inference container? (You probably do not.)
• Does your ML environment have network egress controls? (It almost certainly does not.)

If you answered "no" to three or more of these, your ML pipeline has the same exposure LiteLLM's maintainers had before March 24.

The AI supply chain is not a future problem. It got exploited this week, targeting the single library that sits between your application and every LLM API you call. The fix is not buying another tool. It is applying the dependency management discipline that the ML ecosystem has been skipping for years.

About DeviDevs: We build ML platforms, secure AI systems, and help companies comply with the EU AI Act. devidevs.com