LiteLLM Got Backdoored — And Your Credentials Probably Went With It
If you use LiteLLM — or anything that depends on it — open a terminal right now and run this:
pip show litellm
If the version says 1.82.7 or 1.82.8, stop reading and go rotate every credential on that machine. SSH keys, AWS credentials, Google Cloud tokens, LLM API keys, .env files — all of it. Then come back.
Okay. Let's talk about what happened.
What Is LiteLLM?
If you're not familiar with it, LiteLLM is the plumbing behind a huge chunk of AI applications and agents. It's the library that lets your tools talk to ChatGPT, Claude, Gemini, and 100+ other AI providers through a single unified interface.
97 million downloads a month. Present in 36% of all cloud environments. It's basically everywhere.
They Didn't Attack LiteLLM Directly
Here's the part that makes this attack genuinely scary — the attackers, a group called TeamPCP, didn't go after LiteLLM first.
They went after Trivy — the security scanning tool that LiteLLM used in their own CI/CD pipeline to check for vulnerabilities. Trivy was compromised 5 days earlier in a coordinated campaign.
LiteLLM's pipeline was pulling Trivy without a pinned version. So when the scanner ran, it handed TeamPCP the credentials needed to publish directly to PyPI under the real maintainer's account.
Poisoning the cure to poison the patient. Clever, and genuinely alarming.
What the Malware Actually Did
Two backdoored versions went live on March 24. The payload was a three-stage attack:
Stage 1 — Credential harvester
Swept SSH keys, AWS and Google credentials, Kubernetes secrets, cryptocurrency wallets, LLM API keys, and any .env files it could find. Everything was packaged into an encrypted archive (tpcp.tar.gz) and exfiltrated to a C2 domain registered the night before: models.litellm[.]cloud.
Stage 2 — Kubernetes lateral movement If a Kubernetes service account token was present, it enumerated every node in the cluster and deployed a privileged pod to each one — then chrooted into the host file system from there, jumping from your container to the underlying machine.
Stage 3 — Persistent backdoor
Installed a systemd service (sysmon.service) that polls an attacker-controlled URL every 50 minutes to fetch and run the next-stage payload. Even if you remove LiteLLM, the backdoor stays.
Version 1.82.8 was worse. It injected a malicious .pth file at the wheel root — meaning the payload executed automatically on every Python process startup, not just when LiteLLM was imported. Your Python environment was compromised the moment you installed it.
How It Was Even Caught
Here's the uncomfortable part: the only reason this was discovered within hours instead of weeks was a bug in the malware.
The code had a logic error that caused Python to spawn endless copies of itself until RAM ran out. That crash is what got people's attention.
Without that bug, this runs silently in the background until someone notices credentials being used from unusual locations — which could take days, or never.
PyPI pulled the compromised versions within 3 hours of discovery.
What You Should Do
Check your version:
pip show litellm
If you're on 1.82.7 or 1.82.8:
- Rotate every credential that was on that machine or in your environment variables. SSH keys, cloud credentials, API keys, everything.
- Isolate the affected environment and audit for unexpected changes or outbound network traffic.
- Check for
sysmon.servicerunning as a systemd service — that's the persistence mechanism. - If you were running in Kubernetes, assume node-level compromise and audit privileged pods.
BerriAI (the maintainers) have confirmed the attack and are urging full credential rotation. PyPA has issued an advisory. The safe versions are anything before 1.82.7.
The Bigger Picture
This isn't an isolated incident. TeamPCP has now hit five ecosystems: GitHub Actions, Docker Hub, npm, Open VSX, and PyPI. The pattern is consistent — each compromised environment yields credentials that unlock the next target.
And they've apparently teamed up with LAPSUS$.
Wiz put it well: "By moving horizontally across the ecosystem — hitting tools like LiteLLM that are present in over a third of cloud environments — they are creating a 'snowball effect.'"
The lesson here isn't "don't use open source" — that's not realistic. The lesson is that your supply chain is part of your attack surface. Pinned versions, dependency auditing, and non-human identity monitoring matter. A lot.
If you're building AI systems, LiteLLM is almost certainly in your stack somewhere. Worth doing an audit today even if you're not on the affected versions.
— Cheers, NP