LiteLLM 1.107.0 was compromised: am I affected, and what to do

Symptoms

• You ran an unpinned pip install / upgrade of litellm, or pulled LiteLLM images tagged latest / main-stable, on 2026-10-21 between 11:39 and 14:20 UTC
• pip show litellm reports 1.107.0, or cook.pth, cook.py or sitecustomize.py sit in site-packages
• /tmp/remote_code_loader.lock exists, or there is a detached Python daemon (parent PID 1, working directory /)

Common causes

• Per LiteLLM, the attacker obtained developer GitHub CLI OAuth tokens from logs of an internal LiteLLM deployment (Claude Code can, in some cases, embed the token in a response body that then gets logged), used an org-owner token to disable branch protection, pointed the release workflow at the lookalike repo Berri-AI/litellm and published signed artifacts (investigation ongoing)
• The payload is installed as a .pth file and sitecustomize.py in site-packages, so it runs whenever any Python process starts in that environment, even without importing litellm
• It steals SSH keys, cloud credentials, kube/docker/gh configs, CI secrets, browser passwords, AI coding tool tokens and the provider API keys stored in the LiteLLM proxy database

How to fix

1. Check exposure: pip show litellm; search every venv and image for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py; check whether image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e ever ran. A hit confirms exposure; no hit does not prove you are clean (container and /tmp cleanup remove traces)
2. Do not start with pip install: any Python start in the affected environment (pip included) re-runs the payload. From the shell, delete cook.pth, cook.py, sitecustomize.py and matching __pycache__ .pyc files from every affected site-packages, and kill the daemon holding /tmp/remote_code_loader.lock
3. Reinstall pinned to litellm==1.106.2 (official advice, or any explicit earlier version); better, rebuild venvs and images from scratch and pin images by digest instead of latest
4. Assume exfiltration and rotate: instance/task IAM roles, every provider key in the LiteLLM proxy DB plus master and virtual keys, the DATABASE_URL password, any secret in the environment of any process on the host, and SSH, cloud, GitHub and AI-tool tokens
5. Review audit logs, e.g. AWS CloudTrail GetCallerIdentity calls from the instance role around install time and later use of its credentials from outside your infrastructure
6. Going forward: pin dependencies with hashes (uv pip install --require-hashes / pip --require-hashes), pin images by digest, give CI and proxy hosts least-privilege short-lived credentials, and keep long-lived tokens such as GitHub CLI tokens out of places agents can read or logs can capture

Notes

• Based on LiteLLM’s official incident post (last updated 2026-10-21 20:30 UTC) and the reporter’s issue in the official repo; LiteLLM says it updates the post every two hours — follow it for the latest details
• LiteLLM says enterprise customers using its private registry were not affected
• Our LiteLLM software entry may show the GitHub v1.107.0 tag as the latest version: the tag’s source is clean, but the matching PyPI/Docker artifacts were malicious — install 1.106.2