LiteLLM 1.107.0 hit by a supply-chain compromise: PyPI wheels and Docker images shipped a credential stealer and backdoor; LiteLLM says it is contained and advises pinning 1.106.2

Background and the problem

LiteLLM is the open-source Python library and proxy gateway many AI apps use to reach 100+ model providers; Datadog Security Labs puts it at about 23 million weekly downloads. A gateway holds every provider API key, so a poisoned release reaches far beyond a normal dependency. It is the project's second incident this year, after versions 1.82.7/1.82.8 in March, which led LiteLLM to move releases to a private repo and sign images.

How the attack worked

According to LiteLLM's incident report, the attacker obtained 3 sets of developer GitHub CLI OAuth tokens (LiteLLM believes they came from logs of an internet-exposed internal LiteLLM deployment, and says it observed Claude Code embedding gh tokens in response bodies in specific cases), one of them an org owner's. The attacker disabled branch protection, force-pushed a change pointing the release workflow at the lookalike repo Berri-AI/litellm, and signed and published the poisoned artifacts. JFrog and Datadog found three extra files in the wheels, cook.pth, cook.py and sitecustomize.py, which run on every Python start without importing litellm; they are absent from the sdist and Git tag, so source-only review misses them.

Benchmarks and figures

No benchmarks apply. LiteLLM's timeline: the PyPI release was live from 11:39 to 13:23 UTC; the Docker Hub and GHCR tags v1.107.0, latest, main-latest and main-stable were poisoned from 11:46 UTC, with GHCR cleared by 13:51 UTC and Docker Hub by 14:20 UTC. Socket says its scanner flagged all 7 wheels 7 minutes after publication. No CVE has been assigned yet.

What developers should do

Check with pip show litellm and search for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Do not run pip install first, since any Python process re-triggers the payload: delete the three files and matching .pyc from the shell, kill the daemon holding /tmp/remote_code_loader.lock, then pin litellm==1.106.2, ideally rebuilding images and venvs from scratch. If the host had internet access, assume exfiltration and rotate every provider key in the proxy DB, the master and virtual keys, the DATABASE_URL password and cloud role credentials. Going forward, pin versions and image digests instead of floating latest tags.