The LiteLLM Fiasco

On Mar 24, 2026, Callum McMahon discovered that LiteLLM 1.82.7 and 1.82.8 on PyPI were compromised. Here’s a quick explainer of what happened, how it happened, and what the implications are.

What is LiteLLM?

LiteLLM is very commonly used Python library that works as a proxy server to over 100 LLM providers, e.g. OpenAI, Anthropic. It provides a single format for accessing all of these LLMs, so applications like Cursor allow users to easily switch from one LLM to another.

It is very commonly used and many packages have dependencies on it. It has 97 million downloads per month, and it has 41k stars on Github.

What happened?

LiteLLM Version 1.82.7 and 1.82.8 on PyPI were poisoned with malware which exfiltrates sensitive credentials, including AWS/GCP keys, SSH keys, Kubernetes secrets, and crypto wallets. Version 1.82.8 uses a malicious .pth file that executes the malware every time the Python interpreter starts, even if LiteLLM is not explicitly imported.

How was it discovered?

Callum McMahon did an analysis of how it happened. The attack had a bug that caused his machine to run out of RAM and crash, and that’s how it was discovered. Andrej Karpathy said the poisoned version was only up for less than 1 hour.

How was the attack implemented?

Looks like one of the LiteLLM authors’ github account is compromised, and that may be how the malicious .pth file got into the release. That github account no longer exists.

What do I need to do?

First of all, if you know you installed either of these two versions of LiteLLM, you must rotate all credentials and treat the system as fully compromised. Version 1.82.6 is the last known clean release.

Second, because there are so many packages that depend on LiteLLM, you may have installed these packages indirectly due to dependencies. Run pip show litellm, inspect uv caches (find ~/.cache/uv -name “litellm_init.pth”), and check virtual environments in CI/CD to make sure you don’t have these packages. If you do, see step one and clean up.

The implications

This is a classic supply chain attack. As we have increasingly complex dependency in our software stack, supply chain attacks could be the sneakist. It doesn’t really have anything unique to AI, but it utilizes the increasing popularity of AI libraries. Luckily for us, it was discovered quickly; it could have caused much much more damage.

One novel thing about this attack is that the bug that made it possible for Callum to discover the attack is likely introduced because attackers’ vibe coded the attack. So this time the world didn’t end because AI is not good enough yet. Until next time. On the other hand, Callum also used Claude Code to help him figure out the attack quickly, so AI saved humanity twice this time.