Two versions of LiteLLM — 1.82.7 and 1.82.8 — landed on PyPI with a backdoor baked in. If you ran either one in production, this supply chain attack quietly handed the keys to your AI pipeline to someone you never met: environment variables, API keys, cloud credentials, all of it. LiteLLM is the gateway thousands of teams use to route requests across OpenAI, Anthropic, AWS Bedrock, and Azure OpenAI through a single API. That reach is exactly what made this so bad.
Let me walk through what happened, how the backdoor worked, and the exact steps I'd take before lunch if I found these versions in my lockfiles.
What actually happened
LiteLLM is the most popular AI gateway there is. Hundreds of models, dozens of providers, one API surface. It sits in the middle of your inference stack and, by design, it holds every credential you feed it — because that's its whole job.
The attacker didn't find a clever zero-day in the code. They got into the maintainer's PyPI account. No two-factor authentication. One account, one password, and the moment that fell, they could publish whatever they wanted under a name that thousands of requirements.txt files already trusted. They pushed 1.82.7 and 1.82.8. Anyone who ran an unpinned pip install litellm in that window pulled the malicious code straight into production.
How the backdoor worked
The payload was boring, which is what makes it effective. The compromised versions read the environment — the same environment where your OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS credentials, and Azure secrets live — and shipped them out to an endpoint the attacker controlled.
No crash. No error in your logs. No behavior change your monitoring would flag. Your gateway kept routing requests exactly like it always had, and while it did, it was copying your secrets out the side door. By the time anyone noticed, the credentials were already gone.
The part that should scare you
This is the third major PyPI supply chain attack this year, and the shape of it never changes:
- A widely-used package with a single maintainer
- An account protected by one password and nothing else
- Millions of downstream installs that inherit the malicious version within hours
- Teams that never verify what they actually pulled
Most teams never notice, and that's the real problem. If your pip install runs in CI without hash verification, you are trusting a stranger's account hygiene with your production keys. That's the whole security model, spelled out plainly.
What to do right now
If you touch LiteLLM anywhere, run this today, in order:
- Check your lockfiles. If you're on 1.82.7 or 1.82.8, roll back to 1.82.6 immediately.
- Rotate every credential LiteLLM could see. Every provider key, every cloud secret, every token in that environment. Assume all of it leaked, because it did.
- Audit outbound connections. Pull your cluster logs and look for connections to endpoints you don't recognize. That's your exfiltration channel.
- Add hash verification to CI/CD. Pin exact versions and verify checksums on every
pip install. If a hash doesn't match, the build fails. Non-negotiable.
Rotating keys is the boring, painful step everyone wants to skip. Don't. If the malicious version ran even once with access to a credential, that credential is compromised.
Your pipeline is only as secure as its weakest dependency
I manage 62 Azure subscriptions across production. I've watched a single bad dependency cascade through an environment, and it is not a thing you want to debug at 2 a.m. That experience is why I pin every dependency and verify every checksum, without exception. As a Certified Ethical Hacker, I've trained myself to think like the attacker — and the attacker doesn't break your code, they break the trust you extend to everyone upstream of you.
"Just pip install" feels free. It isn't. The convenience is a loan against your security, and supply chain attacks are how the bill comes due. Every unpinned dependency is a stranger with a copy of your production keys who just hasn't decided to use them yet.
Your AI pipeline is only as secure as its weakest dependency. This week, that dependency was LiteLLM. Next week it'll be something else. So here's the honest question: when was the last time you actually verified the integrity of your Python dependencies?