LiteLLM PyPI Supply Chain Attack: How a Poisoned Package Exposed Developer Credentials

**Software Horror: The LiteLLM PyPI Supply Chain Attack**

Every developer has typed it.

`pip install something`

It feels harmless. Routine. Almost boring.

But as highlighted in this post on X by Andrej Karpathy, https://x.com/karpathy/status/2036487306585268612?s=52, one simple `pip install litellm` recently became something far more serious.

For a short window, a poisoned version of LiteLLM was published to PyPI. And installing it was enough to quietly exfiltrate an alarming list of sensitive data, SSH keys, AWS, GCP and Azure credentials, Kubernetes configs, git credentials, environment variables, API keys, shell history, crypto wallets, SSL private keys, CI/CD secrets, database passwords. The kind of list that makes your stomach drop if you’ve ever managed production systems.

Here’s what makes it worse. LiteLLM sees around **97 million downloads per month**. And it’s not just about developers who intentionally installed it. Any project that depended on LiteLLM, like `dspy`, could have pulled it in automatically. That’s the hidden danger of modern dependency trees. You install one thing, which installs ten more, which install fifty more. Somewhere deep in that pyramid, something can go very wrong.

The malicious version was live for less than an hour. Ironically, a bug in the attack caused a machine to run out of RAM and crash, which exposed it. If that hadn’t happened, it might have lingered quietly for days or weeks.

This is the uncomfortable reality of software supply chains. We’ve been taught that dependencies are like Lego bricks, reusable, efficient, smart. And they are… until one brick is compromised.

Maybe this is a moment to rethink how much we rely on sprawling dependency graphs. To audit more. To pin versions. To reduce what we pull in “just because.”

Because in today’s world, installing a package isn’t just adding functionality.

It’s extending trust.