LiteLLM 1.107.0 compromise: how to check if you're affected

LiteLLM 1.107.0, published to PyPI and Docker on October 21, contained malware that steals cloud, SSH and AI provider credentials. You are affected if any machine or container installed litellm==1.107.0, or pulled the latest, main-latest or main-stable Docker tags, between 11:39 and 14:20 UTC that day. The safe version is 1.106.2.

The first public warning I could find came from @JFrogSecurity about 40 minutes after the upload. It flagged "malicious code in the LiteLLM 1.107.0 PyPI release" and told people to investigate any environment where it ran. That post has since passed 300,000 views. Later that day, developer @ScarletKc wrote up a sharper version for AI developers: the payload goes after Claude, Codex, Cursor and Copilot tokens along with SSH keys and browser cookies, and the advice is to not even run Python on a machine you suspect.

What LiteLLM is, and why this one hurts

LiteLLM is a popular open-source layer that lets code call OpenAI, Anthropic, Google and dozens of other model providers through one interface. Teams often run it as a proxy that holds every provider key the company has. So whoever owns that box owns your keys. According to Wiz's analysis, the stealer even queries the LiteLLM proxy's own database table of stored provider keys.

It is also the second time this year. JFrog notes that versions 1.82.7 and 1.82.8 were backdoored in March, though it sees no evidence tying the two campaigns together.

What happened

LiteLLM's incident page says the attacker held GitHub CLI credentials belonging to three of its developers, one of them an organization owner. They used those to override branch protection and point the release workflow at a lookalike repository, Berri-AI/litellm (the real one is BerriAI/litellm). The pipeline then signed and published the poisoned build. The source code tagged v1.107.0 on GitHub is clean, so reading the code would not have warned you. Only the shipped packages were bad.

How it runs is the nasty part. The package drops three files, cook.pth, cook.py and sitecustomize.py, into the root of site-packages. Python loads those on every startup, so the stealer fires the moment any Python process starts in that environment, even one that never imports LiteLLM. On Linux and macOS a second piece checks in hourly for more code to run.

Wiz reports the attacker started testing stolen AWS instance credentials about four and a half hours after the theft, mostly checking for access to Amazon Bedrock models. That pattern, stealing cloud keys to run AI models on someone else's bill, is often called LLMjacking.

How to check your machines

Don't start with pip show or pip install. Pip is a Python process, and both LiteLLM and JFrog warn that starting Python in an infected environment can trigger the payload again. Use plain shell tools first:

1. Look for the dropped files and the bad package folder: find / -name "cook.pth" 2>/dev/null and find / -type d -name "litellm-1.107.0.dist-info" 2>/dev/null.
2. Look for the marker files: ls /tmp/.pc_once_* /tmp/remote_code_loader.lock. Either one means the payload ran.
3. For Docker, run docker images --digests | grep litellm and compare against the affected digests on LiteLLM's incident page (the main image starts sha256:1bbcb1443bc9).
4. Check outbound logs for traffic to litellm.dev, the attacker's lookalike domain. The real docs live at litellm.ai.

A clean result is not proof. LiteLLM says a match confirms exposure, but no match does not mean the machine is safe.

If you find it

Here is LiteLLM's guidance, in the order it gives it:

Customers on LiteLLM's private enterprise registry were not affected, per the company.

What this means for a small business

You may not run LiteLLM directly, but plenty of AI tools, agents and internal scripts pull it in as a dependency. It's the same lesson as the OpenCode Console breach and this week's PHP2Shell flaws. Anything that holds your API keys is worth attacking now, and "always install the latest" is risky when nobody vets the latest. Pin versions, keep AI keys in one place you can rotate quickly, and know which machines hold them.

If you aren't sure which of your tools touch AI keys or who would rotate them on a day like this, New Face Design's free process audit maps your systems and the people responsible for each.