LiteLLM 1.107.0 shipped a credential stealer for two hours; it runs even where LiteLLM is never imported

On October 21 someone pushed a poisoned release of LiteLLM, the open-source library and proxy that lets one piece of code call many model providers. Version 1.107.0 was live on PyPI from 11:39 to 13:23 UTC, and the Docker images tagged v1.107.0, latest, main-latest and main-stable carried it from 11:46 to as late as 14:20. LiteLLM says its release pipeline was compromised, the bad artifacts came through its normal signed build, and its enterprise build was not hit. Its page, updated at 20:30 UTC that day, calls the incident contained and the investigation open.

What the malware does is the reason to care. Analysts at SafeDep and JFrog report that all seven wheels drop three files into site-packages: cook.pth, cook.py and sitecustomize.py. Python loads them every time it starts, so they run on that machine even in programs that never import LiteLLM. One collects SSH keys, cloud and CI credentials, AI tool tokens, browser passwords and the provider keys in a LiteLLM proxy database. The other checks in every hour for more code to run. The GitHub source tag is clean, so reading the code would not have caught it. JFrog calls it LiteLLM's second hijacking this year, after one in March.

That touches Jon's work in two ways. LiteLLM sits where many companies keep every model key they own, and his business is building AI systems for firms, whose stacks often include it. And LiteLLM's own site now advertises calling decision models such as Jev, the one his agents use most, through a single endpoint.

Jon's agents checked the machine they run on the morning after. None of its 12 Python environments has LiteLLM installed, no repository lists it, the package caches hold no copy, and no site-packages folder contains cook.pth, cook.py or sitecustomize.py. Docker is installed but was not running, and nothing in the repositories pulls a LiteLLM image. His agents reach models through OpenRouter and the makers' own APIs.

What to do about it

• Check every environment, not just the project: find / -name cook.pth -path "*-packages*" 2>/dev/null, plus pip show litellm in each virtualenv and docker images | grep litellm.
• Run those checks from outside a suspect environment: any Python that starts there, pip included, runs the hooks again.
• If 1.107.0 or one of those image tags ran in the window, LiteLLM says to assume the theft succeeded, rebuild images and virtualenvs from scratch, and rotate everything the host could reach: cloud roles, every provider key in the proxy database, its master and virtual keys, the database password and any secret in a process's environment. Removing the package repairs none of that.
• Pin to 1.106.2 or another exact earlier version, and pin Docker images by digest, not by latest.

What nobody knows yet

How the attacker got into the pipeline. LiteLLM's account is provisional, and its promised later update had not appeared by the morning of October 22. How many hosts installed it in under two hours, and whether this is the same group as in March; JFrog finds no link.

What to watch

LiteLLM's follow-up on the attack chain. And October 27, when LiteLLM plans to disclose a separate vulnerability its enterprise customers already have a fix for.