How do I check if I installed the bad LiteLLM release?

LiteLLM says to run pip show litellm and treat the environment as compromised if it reports 1.107.0. Users should also check whether any container ran the affected Docker image digest and search the filesystem for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. LiteLLM warns that finding one confirms exposure, but not finding one does not prove the host is clean.

Which LiteLLM credentials should I rotate after the compromise?

LiteLLM asks affected users to rotate everything the host could reach: the instance or task IAM role, every provider key stored in the LiteLLM proxy database, the master and virtual keys, the DATABASE_URL password, and any secret in the environment of any process on the host. It also suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time.

Why should I not just run pip install to upgrade LiteLLM?

The LiteLLM 1.107.0 payload runs on every Python start in the affected environment, so running pip there launches the malware again. LiteLLM's guidance is to delete cook.pth, cook.py, sitecustomize.py and their cached .pyc files from the shell first, kill the daemon holding /tmp/remote_code_loader.lock, then reinstall litellm==1.106.2, ideally rebuilding the image or venv from scratch.

How did attackers get a malicious LiteLLM release onto PyPI?

LiteLLM says the GitHub accounts of three engineers were used, apparently through stolen GitHub CLI OAuth tokens, to change the release pipeline, approve the production gate and delete workflow records. SafeDep found the PyPI build matched a later main-branch commit plus an injected cook folder, not the v1.107.0 tag. LiteLLM has not yet found how the tokens were stolen.

LiteLLM · 2026-10-21 · major

LiteLLM 1.107.0 compromised — PyPI and Docker builds stole credentials

LiteLLM's release pipeline was hijacked and shipped a malicious v1.107.0 to PyPI and Docker. It stole SSH, cloud and LLM provider keys and ran an hourly backdoor. Pin 1.106.2 and rotate every reachable secret.

SafeDep banner for its analysis of the compromised LiteLLM 1.107.0 package on PyPI

A hijacked LiteLLM release shipped a credential stealer and backdoor to PyPI and Docker for about two hours.

Quick facts

Bad version	litellm 1.107.0 (all seven wheels)
PyPI window	11:39–13:23 UTC, Oct 21, 2026
Docker tags hit	v1.107.0, latest, main-latest, main-stable
Safe pin	litellm==1.106.2
Not affected	Private enterprise release, versions before 1.107.0
Exfil domain	www.litellm.dev (lookalike)

What is it?

LiteLLM v1.107.0, published on October 21, 2026, was built by attackers and pushed through LiteLLM's own release pipeline to PyPI, Docker Hub and GHCR. The maintainers say every earlier version is safe and that the bad artifacts have been pulled. The official v1.107.0 source tag on GitHub does not contain the malicious files.

How does it work?

The poisoned wheels drop three files into site-packages: cook.pth, cook.py and sitecustomize.py. Python loads them on every interpreter start, even without importing LiteLLM. One payload collects SSH keys, cloud credentials, CI secrets, AI tool tokens and the provider keys stored in a LiteLLM proxy database, encrypts them and uploads them to the lookalike domain www.litellm.dev. The other starts a detached daemon that checks a GitHub-hosted file every hour and runs whatever code that server returns. According to LiteLLM, three engineers' GitHub accounts were used, apparently through stolen GitHub CLI OAuth tokens: one changed the pipeline, one approved the production gate, and one deleted workflow records.

Why does it matter?

LiteLLM is a gateway that often holds the API keys for every model provider a team uses, so one infected proxy host can leak a whole company's LLM spend and cloud access. Anyone who installed the release or pulled the latest or main-stable image in the window should treat that host as compromised, not just upgrade. The incident follows an earlier LiteLLM PyPI compromise in March, which makes pinning versions and image digests a must for AI gateways.

Who is it for?

teams running LiteLLM as an SDK or proxy, especially from Docker latest tags

Frequently asked questions

How do I check if I installed the bad LiteLLM release?: LiteLLM says to run pip show litellm and treat the environment as compromised if it reports 1.107.0. Users should also check whether any container ran the affected Docker image digest and search the filesystem for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. LiteLLM warns that finding one confirms exposure, but not finding one does not prove the host is clean.
Which LiteLLM credentials should I rotate after the compromise?: LiteLLM asks affected users to rotate everything the host could reach: the instance or task IAM role, every provider key stored in the LiteLLM proxy database, the master and virtual keys, the DATABASE_URL password, and any secret in the environment of any process on the host. It also suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time.
Why should I not just run pip install to upgrade LiteLLM?: The LiteLLM 1.107.0 payload runs on every Python start in the affected environment, so running pip there launches the malware again. LiteLLM's guidance is to delete cook.pth, cook.py, sitecustomize.py and their cached .pyc files from the shell first, kill the daemon holding /tmp/remote_code_loader.lock, then reinstall litellm==1.106.2, ideally rebuilding the image or venv from scratch.
How did attackers get a malicious LiteLLM release onto PyPI?: LiteLLM says the GitHub accounts of three engineers were used, apparently through stolen GitHub CLI OAuth tokens, to change the release pipeline, approve the production gate and delete workflow records. SafeDep found the PyPI build matched a later main-branch commit plus an injected cook folder, not the v1.107.0 tag. LiteLLM has not yet found how the tokens were stolen.

Try it

pip show litellm — if it says 1.107.0, remove cook.pth, cook.py and sitecustomize.py from the shell, then reinstall litellm==1.106.2