Skip to content

LiteLLM 1.107.0 was poisoned for two hours: check your Python environments

On 21 October 2026 attackers published a malicious LiteLLM 1.107.0 to PyPI and to the project's Docker images. The payload ran every time Python started, even when LiteLLM was never imported, and sent cloud, AI and developer credentials to a lookalike domain. The release was pulled within hours. Any environment that installed it stays compromised until it is cleaned and its secrets are rotated.

What happened

  • LiteLLM is a popular gateway that lets apps and AI agents call many model providers through one API, so it often holds every provider key an organisation has.
  • The attackers used stolen GitHub tokens from LiteLLM engineers to run the release workflow and publish 1.107.0 on 21 October 2026. On PyPI it was online from 11:39 UTC until it was quarantined at 13:20 UTC. The affected Docker images were removed at 13:53 UTC.
  • The release added three files to site-packages: cook.pth, cook.py and sitecustomize.py. Python runs them at every start-up, and deleting the litellm package does not remove them.
  • They collect cloud credentials (AWS, Azure, GCP, Kubernetes, Docker), SSH, GPG and TLS keys, Git, npm and PyPI tokens, .env files, browser passwords and cookies, AI tool sessions and LLM provider keys. When the LiteLLM proxy database is configured, they also read the stored provider keys. The data goes to litellm[.]dev.
  • It is the second compromise of LiteLLM releases in 2026.

Who is affected

Anyone who installed or pulled, on 21 October 2026:

  • litellm==1.107.0 from PyPI (all wheels), or
  • the Docker images tagged v1.107.0, or latest, main-latest or main-stable while they pointed to it, on ghcr.io (berriai/litellm, litellm-database, litellm-non_root) or Docker Hub (litellm/litellm).

CI pipelines and containers that float on latest are the most likely to have picked it up without anyone noticing.

What to do

  1. Find exposure without starting Python in a suspect environment (every start runs the payload again). Search lockfiles, requirements files, image lists and CI logs from 21 October for 1.107.0.
  2. Isolate any affected host or container, keep evidence, and rebuild it from a clean image. If you must clean in place, remove the three files and their __pycache__ entries.
  3. From a clean machine, rotate everything the process could read: LiteLLM provider keys and master key, database credentials, cloud and Kubernetes credentials, registry and package tokens, SSH, GPG and TLS keys, AI tool sessions and .env secrets.
  4. Check logs for use of those credentials after the install, and network logs for requests to litellm[.]dev/healthcheck.
  5. Pin litellm==1.106.2, the last release before the compromise, and pin container images by verified digest, not by tag.

Check

These read files only. They do not start Python.

# Requirements and lock files (poetry.lock, uv.lock and Pipfile.lock put the version on a later line)
grep -Rn -A3 "litellm" --include="*.txt" --include="*.toml" --include="*.lock" . | grep "1\.107\.0"

# Payload files in any Python environment on the host
find / \( -path "*site-packages*" -o -path "*dist-packages*" \) \
  \( -name "cook.pth" -o -name "cook.py" -o -name "litellm-1.107.0.dist-info" \) 2>/dev/null

# sitecustomize.py can be legitimate: list every copy and compare it with the hashes in the Endor Labs advisory
find / \( -path "*site-packages*" -o -path "*dist-packages*" \) -name "sitecustomize.py" 2>/dev/null

# Local LiteLLM images and their digests
docker images --digests | grep -i litellm

Other indicators from the analyses: requests to www.litellm[.]dev/healthcheck or to the letters9813/pythonclient-test path on raw.githubusercontent.com, the files /tmp/.pc_once_* and /tmp/remote_code_loader.lock, and the environment variable PRIVCOLLECT_ACTIVE=1.

Why it matters for security

An AI gateway is a key vault with a network connection. This attack never needed the application to run: a .pth file in a dependency was enough. Treat packaging files as code, alert on new .pth or sitecustomize.py files in third-party packages, and keep provider keys for AI gateways scoped and rotatable.

Sources