LiteLLM PyPI Supply Chain Attack: What Happened and What To Do
On March 24, 2026, LiteLLM PyPI versions 1.82.7 and 1.82.8 were published with credential-stealing malware. The compromised package had ~95 million monthly downloads and affected downstream projects including DSPy, CrewAI, and any tool using LiteLLM as a dependency. The attack was part of TeamPCP's month-long supply chain campaign.
~3-5 hours
95M+
1.82.7, 1.82.8
1.82.6
Timeline
TeamPCP compromises Trivy via pull_request_target vulnerability in GitHub Actions
Campaign escalates: backdoored Trivy binaries, 45+ npm packages, Docker Hub images poisoned
Checkmarx KICS compromised; attacker registers fraudulent domain models.litellm.cloud
LiteLLM v1.82.7 published to PyPI via hijacked maintainer account (krrishdholakia). Malicious code injected into proxy_server.py
LiteLLM v1.82.8 published 13 minutes later, adding litellm_init.pth - a .pth file that executes on every Python invocation, even without importing litellm
Callum McMahon's machine crashes from RAM exhaustion - a bug in the malware caused an exponential fork bomb, leading to discovery
Initial GitHub issue #24512 filed and quickly closed as "not planned" (likely by compromised account)
BerriAI publishes official disclosure (GitHub issue #24518) with full timeline
PyPI quarantines entire litellm package. BerriAI engages Google Mandiant for investigation
What The Malware Stole
The 332-line credential harvester performed a systematic sweep of the compromised system. Data was encrypted with AES-256-CBC (session key wrapped with RSA-4096) and exfiltrated to models.litellm.cloud - a fraudulent domain, not legitimate LiteLLM infrastructure.
SSH & Git
id_rsa, id_ed25519, id_ecdsa, authorized_keys, .gitconfig, .git-credentials
Cloud Credentials
AWS IMDS + Secrets Manager, GCP application_default_credentials, Azure ~/.azure/
Kubernetes
Service account tokens, K8s API secrets, deployed privileged pods for lateral movement
Environment & API Keys
All env vars, recursive .env search (6 dirs deep) - every API key you had
Database & CI/CD
.pgpass, my.cnf, redis.conf, Terraform state, Jenkinsfile, WireGuard configs
TLS/SSL & Docker
.pem, .key, .p12, Let's Encrypt certs, Docker credentials, npm tokens
Crypto Wallets
Bitcoin wallet.dat, Ethereum keystores, Solana validator keypairs, Monero, etc.
System & History
/etc/passwd, /etc/shadow, auth logs, bash/zsh history
How The Attack Worked
Stage 1: Initial Compromise via CI/CD
LiteLLM used the already-compromised Trivy security scanner in its CircleCI pipeline. The backdoored Trivy binary leaked LiteLLM's PyPI publishing token and GitHub PAT, giving TeamPCP direct access to publish packages on PyPI.
Stage 2: Dual Payload Delivery
v1.82.7 injected 12 lines into proxy_server.py (lines 128-139), executing at module import time.
v1.82.8 added litellm_init.pth (34KB). Python's site.py processes .pth files at interpreter startup, so the payload ran on every Python invocation, even without importing litellm. Both used double base64-encoded payloads and subprocess execution to evade static analysis.
Stage 3: Kubernetes Lateral Movement
If a Kubernetes service account token was found, the malware deployed privileged pods to each cluster node in the kube-system namespace - with hostPID, hostNetwork, and the entire host filesystem mounted at /host.
Stage 4: Persistent Backdoor
Installed at ~/.config/sysmon/sysmon.py as a systemd user service labeled "System Telemetry Service." Polls checkmarx.zone/raw every 50 minutes to download and execute arbitrary binaries. Kill switch checks for "youtube.com" in the response.
The Bug That Saved Everyone
The .pth launcher spawns a child Python process via subprocess.Popen. But because .pth files trigger on every interpreter startup, the child process re-triggered the same .pth file, creating an exponential fork bomb. Callum McMahon's machine ran out of RAM and crashed - which is how the attack was discovered within hours. Without this accidental fork bomb, the malware could have gone undetected for days or weeks.
Downstream Impact
LiteLLM is a popular AI API proxy with ~95 million monthly PyPI downloads. Any pip install that resolved to litellm >=1.82.7 during the attack window pulled in the compromised code, including transitive dependencies.
| Package | Dependency | Impact |
|---|---|---|
| dspy | litellm>=1.64.0 | Stanford NLP framework; transitive install pulls compromised version |
| crewai | litellm (direct) | Users reported token theft from .git-credentials |
| browser-use | litellm (direct) | Credential theft reported |
| prodigy-plugins | via dspy → litellm | Explosion/spaCy ecosystem affected transitively |
| MCP plugins | varies | Cursor users affected via MCP plugin transitive deps |
What To Do Right Now
Check if you installed the compromised version
Run: pip show litellm - if version is 1.82.7 or 1.82.8, you are affected. Also check pip install logs and lock files.
Rotate ALL credentials immediately
SSH keys, API keys, cloud tokens (AWS/GCP/Azure), database passwords, git credentials, npm tokens. Assume everything was exfiltrated.
Check for the persistent backdoor
Look for ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service. Remove both. Check /tmp/pglog for suspicious binaries.
Audit Kubernetes clusters
Search for unauthorized pods in kube-system namespace, especially those with privileged: true, hostPID, and hostNetwork access.
Review cloud audit logs
Check AWS CloudTrail, GCP Audit Logs, Azure Activity Log for unauthorized access from unfamiliar IPs since March 24.
Pin your dependencies
Use exact version pins in requirements.txt. Consider using pip-audit, socket.dev, or similar tools to scan for known vulnerabilities in your dependency tree.
The Bigger Picture for AI Developers
LiteLLM is a unified proxy for 100+ LLM providers - a useful abstraction, but also a high-value target. A single compromised dependency gave attackers access to every API key, cloud credential, and secret on the machine.
This attack highlights a growing tension in AI development: the ecosystem encourages deep dependency trees (frameworks that depend on proxy libraries that depend on utility packages), but each dependency is an attack surface. Every pip install is an act of trust.
Practical takeaways: pin versions explicitly, audit transitive dependencies, prefer minimal dependency approaches when possible, and use tools like pip-audit or socket.dev in CI. For AI API routing specifically, consider whether you need a universal proxy or a focused integration with only the providers you actually use.
TeamPCP Campaign Timeline
The LiteLLM compromise was the latest in a month-long cascading supply chain campaign. The attacker compromised one tool, used stolen credentials to compromise the next.
| Date | Target | Ecosystem |
|---|---|---|
| Feb 28 | Trivy (initial compromise) | GitHub Actions |
| Mar 19-20 | Trivy expansion + 45+ npm packages | GitHub Actions, npm |
| Mar 22 | Docker Hub images | Docker Hub |
| Mar 23 | Checkmarx KICS + OpenVSX | GitHub Actions, OpenVSX |
| Mar 24 | LiteLLM (PyPI) | PyPI |
Related on LM Market Cap
Sources
Versions 1.82.7 and 1.82.8 published to PyPI on March 24, 2026 were compromised. Version 1.82.6 and earlier are safe. The malicious versions were uploaded directly to PyPI using a hijacked maintainer account, bypassing the normal GitHub release process.
The malware performed a comprehensive credential sweep: SSH keys, AWS/GCP/Azure credentials, Kubernetes service account tokens, environment variables (including all API keys), database passwords, git credentials, shell history, cryptocurrency wallets, TLS/SSL private keys, CI/CD secrets, and Docker credentials. Data was encrypted with AES-256-CBC and exfiltrated to a fraudulent domain.
Callum McMahon of Futuresearch discovered it when an MCP plugin in Cursor pulled litellm as a transitive dependency. A bug in the malware caused an exponential fork bomb (the .pth file re-triggered on every Python subprocess), crashing his machine by exhausting RAM. Without this bug, the attack could have gone undetected for days or weeks.
Yes, potentially. Any package that depends on litellm could have pulled in the compromised version during the 3-5 hour attack window. DSPy (Stanford NLP), CrewAI, browser-use, and Prodigy Company Plugins were confirmed affected. Check your pip install logs and installed version with: pip show litellm.
Immediately: 1) Rotate ALL credentials (API keys, SSH keys, cloud tokens, database passwords). 2) Check for the persistence backdoor at ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service. 3) Audit Kubernetes clusters for unauthorized pods in kube-system namespace. 4) Review cloud provider audit logs for unauthorized access. 5) Downgrade to litellm 1.82.6 or pin versions explicitly.
The attack was attributed to TeamPCP, the same threat actor behind a month-long cascading supply chain campaign that compromised Trivy (Feb 28), npm packages (Mar 20), Docker Hub images (Mar 22), and Checkmarx KICS (Mar 23). LiteLLM was compromised because it used the already-compromised Trivy scanner in its CI/CD pipeline, which leaked the PyPI publishing token.