Your `pip install` Just Stole Your SSH Keys: The LiteLLM Supply Chain Attack Explained

#security #ai #python #llm

A single pip install litellm==1.82.8 was enough to drain everything off your machine. No suspicious imports. No weird prompts. Just a package install, and your AWS credentials, SSH keys, and API keys were already heading to an attacker's server.

Here's what happened, why it's scary, and what you can actually do about it.

What Happened

On March 24, 2026, LiteLLM version 1.82.8 landed on PyPI with a malicious file bundled inside: litellm_init.pth.

That .pth extension is why this attack is so nasty.

Python automatically runs .pth files in your site-packages directory every time the Python interpreter starts. No import needed, no user interaction. The attacker hid a double base64-encoded payload inside this file. The moment Python ran, the payload ran too.

What did it grab? Pretty much everything:

All your environment variables (OPENAI_API_KEY, AWS_SECRET_ACCESS_KEY, all of it)
SSH private keys (~/.ssh/id_rsa, id_ed25519, and more)
AWS, GCP, Azure, and Kubernetes credentials
Git credentials and .gitconfig
Shell history (~/.bash_history, ~/.zsh_history)
Docker configs, npm tokens, database passwords
Crypto wallet files

Then it encrypted everything with AES-256, wrapped the key with a hardcoded RSA-4096 public key, and shipped it all off to https://models.litellm.cloud/. Note that domain: litellm.cloud, not the real litellm.ai. Classic.

Why the Scale Is Scary

LiteLLM gets 97 million downloads per month. That alone is a huge problem.

But supply chain attacks don't stop at the direct install. They travel through dependency trees. If you installed dspy, langchain, or any of the other popular AI packages that depend on litellm>=1.64.0, you were also exposed without ever typing pip install litellm yourself.

The attack was only live for about an hour. It got discovered almost by accident: a developer's machine ran out of RAM and crashed because the payload was executing inside Cursor through an MCP plugin that pulled in litellm as a transitive dependency. A bug in the attacker's own code gave them away.

If that bug wasn't there, this could have run quietly for days or weeks across thousands of CI/CD pipelines, dev machines, and prod servers. Nobody would have noticed.

The Real Problem: You Can't See What's Inside Your Dependencies

When you run pip install something, you're not just installing one thing. You're pulling in a whole tree of packages, and any one of them could be compromised.

This isn't new, but it's getting worse as the AI package ecosystem keeps exploding. New packages, new versions, new dependencies dropping every single day. The attack surface is growing way faster than anyone can audit it.

We're taught to think of dependencies as a good thing. Reusable building blocks, standing on the shoulders of giants, all that. The LiteLLM incident is a reminder that every dependency is also a trust decision, and most of us are making those decisions without really thinking about it.

What You Should Actually Do

If you installed litellm 1.82.8:

Check for litellm_init.pth in your site-packages/ directory
Rotate everything: every API key, SSH key, and cloud credential that was on that machine
Check any CI/CD environment where litellm might have been installed too

Going forward:

Pin your dependencies. Exact version locks (==) in production instead of >=. It won't stop a poisoned release from getting in if you're on that version, but it stops silent upgrades pulling in something bad later.
Use lockfiles. pip-compile, poetry.lock, uv.lock, whatever fits your setup. Know exactly what you're running.
Audit transitive dependencies. pip-audit and safety scan your full dependency tree for known issues. Worth running in CI.
Don't pip install as root. Limits how much damage a compromise can actually do.
Keep an eye out for .pth files. They're a legit Python feature, but they're also a perfect delivery mechanism for malware. If you see one in site-packages from a package you don't recognise, that's worth investigating.

Can We Do Better Than Grep?

Most of the advice above is reactive. It helps you recover or reduce damage after something gets in. What's actually hard is knowing before you run anything that a package can even reach your credentials.

This is the gap I've been trying to close with something I'm building called ReachScan. The idea is pretty simple: instead of just matching against a list of known bad packages, it maps what a codebase or its dependencies can actually reach: filesystem paths, environment variables, system resources. If a package has no business touching ~/.ssh/, you should know that before it runs, not after.

It won't catch everything. But knowing the capability surface of what you're about to install is a lot better than just hoping nothing in the tree is malicious.

The Uncomfortable Truth

Karpathy put it well after this incident: the way we think about dependencies needs to change. The whole "building pyramids from bricks" model assumes the bricks are trustworthy. In 2026, that's a harder assumption to stand behind.

That doesn't mean stop using dependencies. That's not realistic. It just means:

Be deliberate about what you pull in
Actually understand what each dependency can do on your machine
Have a rotation plan for credentials that treats compromise as a when, not an if

The LiteLLM attack got caught by luck. The next one might not be.