LiteLLM 1.107.0 Compromised: Python Startup Hooks Steal Cloud, AI, and Proxy Credentials | Endor Labs

What it is

litellm 1.107.0 was published to PyPI on 21 October 2026 from a source revision that is not the official v1.107.0 tag. LiteLLM's application code is unmodified, and the attack sits in packaging. The release is now quarantined, and 1.106.2 is the latest release on PyPI. Container images are also affected: deployments that pulled latest, main-latest or main-stable from ghcr.io/berriai/litellm may have received the malicious image without choosing 1.107.0. The build provenance shows the release workflow dispatched with "source_owner": "Berri-AI", a lookalike of the real BerriAI organization. The post says it does not establish how that override was authorized.

How it works

One added line in the Maturin config, data = "cook", copies three files into site-packages: cook.pth, cook.py and sitecustomize.py. They run on every Python start in that environment, whether or not the app imports LiteLLM.

• cook.pth contains import cook, which runs a 61,000-byte encoded collector in a daemon thread. It sets PRIVCOLLECT_ACTIVE so child processes do not collect again. After a successful upload it writes /tmp/.pc_once_72129118c59f5636c0bb.
• The collector has 16 modules. One queries LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, which hold the proxy's provider keys and model config.
• Results are encrypted (AES-256-CBC, key wrapped with RSA-OAEP) and POSTed to http://www.litellm.dev/healthcheck with header X-Token: XWiA8gZNa7NcX2XRoAEb. The response is not executed.
• sitecustomize.py holds a second copy of the collector and a loader. It detaches with fork and setsid, takes /tmp/remote_code_loader.lock, and every hour reads a domain from raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt. It then fetches http://<domain>/codepy and execs it with no signature or hash check. The operator can change the pointer file at any time without a new release.

The official tag lacks the data line and the cook/ directory, so reviewing the tag shows nothing. The sdist was built from the malicious revision, but the packager left cook/ out of the archive.

What to do

Find exposure without running the environment's Python:

grep -rnE 'litellm[=><~!]*=?\s*1\.107\.0' --include='*.txt' --include='*.lock' --include='*.toml' --include='*.cfg' .
find / -path '*site-packages/litellm-1.107.0.dist-info' -type d 2>/dev/null
find / -path '*site-packages/cook.pth' -type f 2>/dev/null
docker image inspect --format '{{.Id}} {{join .RepoDigests " "}}' $(docker images -q) 2>/dev/null | \
  grep -E '1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e|bd1aeee419ea36da9aa2b657288da4101887be468f020ac63d22ba6ed84a3ea5|56b74573eed6e4aafe4b50603dbe7853e0345f188c8e44a09f1098caf1f4bcdf'
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.status.containerStatuses[*].imageID}{"\n"}{end}' | \
  grep -E '1bbcb1443bc962|bd1aeee419ea36|56b74573eed6e4'

Also check CI logs and dependency caches from 21 October 2026, including any unpinned litellm install.

Contain the host:

• Do not start Python or pip in an affected environment, because each start re-runs the collector and can relaunch the loader.
• Isolate the host from the network and preserve process listings, filesystem state and egress logs. Inspect with find, sha256sum, ps and the container runtime.
• Kill any detached loader process, then delete cook.pth, cook.py, sitecustomize.py and their __pycache__ entries. Uninstalling litellm leaves these files behind. Rebuilding from a clean base is preferred.
• Match sitecustomize.py by hash or content, since the filename alone can be legitimate.

Rotate from a clean machine if Python ran after install:

• provider keys stored in the proxy database
• the proxy master key and database credentials
• AWS, Azure and GCP credentials
• Kubernetes and registry tokens
• Git, npm and PyPI tokens
• SSH, GPG and TLS keys
• AI tool sessions (Claude, Codex, Gemini, Cursor, Copilot)
• everything in the process environment or .env files

Then review audit logs for use of those credentials after install time.

Hunt in network logs for POSTs to www.litellm.dev/healthcheck, requests to the letters9813/pythonclient-test path, and any path ending in /codepy. Block that repository path only, since blocking all of raw.githubusercontent.com breaks legitimate builds.

Restore:

pip install 'litellm==1.106.2'

Pin images by digest (ghcr.io/berriai/litellm@sha256:<verified 1.106.2 digest>) and block 1.107.0 in your package proxy.

Longer term, the post suggests reviewing [tool.maturin] and [tool.setuptools] like source, alerting on new .pth files or sitecustomize.py in third-party wheels, and checking that provenance names the expected repository owner.

Caveats

A missing /tmp/.pc_once_* marker does not mean a host is clean: failed uploads, tmp cleanup and container replacement all leave none. Emptying the loader's pointer file disables only the loader, not the collector in cook.pth. The page does not say how the lookalike Berri-AI source owner got release access. The package hash tables did not appear in the fetched text.