LiteLLM Supply Chain Attack: PyPI Compromise Targets AI Infrastructure
On March 24, 2026, malicious versions of LiteLLM—one of the most popular LLM proxy libraries—were published to PyPI. The attack bypassed normal release processes entirely: no corresponding tags exist on GitHub. The maintainer’s account appears to be fully compromised, with the related GitHub issue closed as “not planned” and flooded with bot spam to suppress discussion.
This is not a theoretical vulnerability. This is active exploitation of AI infrastructure at scale.
How the Attack Works
The malware uses a .pth file (litellm_init.pth) that Python executes automatically on interpreter startup—no import required. Once installed, every Python process in the environment triggers the payload.
A Python script harvests sensitive files: SSH private keys, .env files, AWS/GCP/Azure credentials, Kubernetes configs, database passwords, .gitconfig, shell history, and crypto wallet files. It also runs commands to dump environment variables and query cloud metadata endpoints (IMDS, container credentials).
Collected data is encrypted with a hardcoded 4096-bit RSA public key using AES-256-CBC, bundled into a tar archive, and POSTed to models.litellm.cloud—a domain that is not part of legitimate LiteLLM infrastructure.
If a Kubernetes service account token is present, the malware reads all cluster secrets across all namespaces and attempts to create privileged alpine:latest pods on every node in kube-system. Each pod mounts the host filesystem for full access.
A backdoor is installed at ~/.config/sysmon/sysmon.py with a systemd user service for automatic restart. On Kubernetes nodes, the same persistence mechanism is deployed via the privileged pods.
Discovery: A Bug in the Malware
The attack was discovered when the package was pulled as a transitive dependency by an MCP plugin. The .pth launcher spawns a child Python process, but because .pth files trigger on every interpreter startup, the child re-triggers the same .pth—creating an exponential fork bomb that crashed the host machine.
The fork bomb is actually a bug in the malware. Without it, the attack might have gone unnoticed for much longer.
Are You Affected?
pip show litellm | grep Versionfind ~/.cache/uv -name "litellm_init.pth" 2>/dev/nullpip cache list | grep litellmls -la ~/.config/sysmon/sysmon.py 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/nullkubectl get pods -n kube-system | grep node-setup
kubectl get secrets --all-namespaces -o name | wc -lImmediate Remediation
pip cache purge and rm -rf ~/.cache/uvkube-system matching node-setup-*The Bigger Picture
LiteLLM is used by thousands of AI applications. It’s pulled as a transitive dependency by MCP plugins, LangChain integrations, and countless internal tools. A single compromised package cascades through the entire AI supply chain.
This attack demonstrates several uncomfortable truths:
-
PyPI trust is fragile. Packages can be uploaded directly without matching GitHub releases. Maintainer account compromise = total package compromise.
-
Transitive dependencies are invisible attack surface. The affected machine wasn’t running LiteLLM directly—it was pulled by an MCP plugin.
-
AI infrastructure is uniquely valuable. The malware specifically targets credentials that would give access to cloud resources, Kubernetes clusters, and sensitive data—exactly what AI systems need to function.
-
Detection relies on luck. This attack was caught because of a bug in the malware. How many similar attacks have succeeded silently?
Supply Chain Security is AI Security
At Rogue, we’ve been warning about AI supply chain risks since our founding. The attack surface isn’t just your model or your prompts—it’s every dependency your AI system touches.
If you’re building or deploying AI systems, you need:
- Dependency pinning and lockfiles to prevent automatic upgrades to compromised versions
- Artifact verification to detect packages that don’t match their source repositories
- Runtime monitoring to catch unexpected network connections and file access
- Credential isolation so a single compromise doesn’t cascade to your entire infrastructure
The LiteLLM attack won’t be the last. The question is whether you’ll catch the next one before it catches you.