LiteLLM 1.107.0 shipped a credential stealer on PyPI and Docker: how to check and what to rotate

If you installed litellm==1.107.0 or pulled a LiteLLM proxy image tagged latest, main-latest or main-stable on October 21, 2026, treat that host as compromised. Pin 1.106.2, rebuild from a clean image, and rotate every secret the process could read. That includes the provider keys stored in your LiteLLM proxy database. The security report on the LiteLLM repo and analyses from Socket and Upwind describe the same payload.

Builder question this answers: I use LiteLLM as a library or run its proxy. Am I affected, and what do I do first?

What was shipped

Upwind’s researchers report that all seven 1.107.0 wheels (macOS, Linux and Windows) carry three extra files that pip installs into the root of site-packages: cook.pth, cook.py and sitecustomize.py. The malicious code is not in the v1.107.0 git tag. The report says it was added to the build tree before the wheels were built. The sdist has no payload files, but its pyproject.toml was altered.

Python runs .pth lines and imports sitecustomize every time the interpreter starts. So the payload runs even if your code never imports LiteLLM, and even when you only run pip. According to the report, cook.py is a stealer that collects:

• SSH, GPG and TLS private keys, .env files, and Git, npm and PyPI credentials
• AWS, Azure, Google Cloud, Kubernetes, Docker and Vault credentials, plus cloud metadata tokens
• AI-tool credentials, including Claude, Codex, Gemini and Cursor config files
• environment variables of every process it can read
• if DATABASE_URL is set, the contents of LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, which hold your upstream provider keys

The data is encrypted and POSTed to www.litellm.dev, a lookalike domain that is not the project’s litellm.ai. A detached loader in sitecustomize.py checks a GitHub file every hour for a domain to download and exec() Python from. That file was empty when Socket checked, but Socket warns the operator could fill it at any time.

How it got published

Socket found the container image’s build provenance. It shows the official release workflow building from Berri-AI/litellm, a lookalike of BerriAI/litellm with one extra hyphen. In the issue thread, LiteLLM maintainers said the malicious actions came through three engineers’ GitHub accounts, apparently via stolen GitHub CLI OAuth tokens. One account triggered the release run and another approved it. They said the tokens were revoked, all but one user was removed from the GitHub org, and the original attack vector had not yet been found.

Status

• PyPI: 1.107.0 was removed. The PyPI project page now lists 1.106.2 as the latest release.
• Docker: Socket saw ghcr.io/berriai/litellm tags v1.107.0, latest, main-latest and main-stable all pointing at the infected image index sha256:1bbcb1443bc9…. The reporters list litellm-database, litellm-non_root and docker.io/litellm/litellm as affected too. In a 14:32 UTC update, maintainers said the malicious Docker images had been removed. The reporters’ latest status says the floating tags no longer point at the 1.107.0 image.
• Clean versions: The reporters checked every wheel of 1.103.6 through 1.106.2, and both 1.107.0 release candidates, and found them clean. Maintainers ask open-source users to pin 1.106.2 or another release published before the incident. Enterprise customers who pull from LiteLLM’s private registry are not affected.

What to do now

1. Don’t start with pip. Starting the affected interpreter runs the payload again. Upwind suggests pip show litellm to find installs. Run it only in environments you know are clean, and use lockfiles, build logs and image digests for everything else.
2. From the shell, delete cook.pth, cook.py, sitecustomize.py and any matching __pycache__ files from every affected site-packages. Kill the detached Python process that holds /tmp/remote_code_loader.lock. Better still, rebuild the venv or image from scratch.
3. Reinstall pinned to litellm==1.106.2, and pin container images by digest instead of floating tags.
4. Assume the data was stolen if the host had outbound internet. A /tmp/.pc_once_72129118c59f5636c0bb marker confirms an upload. If there is no marker, that proves nothing.
5. Rotate cloud roles, the proxy master and virtual keys, every provider key stored in the proxy DB, the DATABASE_URL password, and any secret in the environment. Then check CloudTrail for GetCallerIdentity calls from the instance role.

If you route models through LiteLLM, as in our Mercury 3 API guide, check your pin before your next deploy. For another attack that targeted AI developer tooling, see our Miasma worm checklist. More builder news is on the 7minai homepage.

Sources: BerriAI/litellm issue #47826 (Upwind report and maintainer updates) · Socket: LiteLLM PyPI package and Docker images compromised · Upwind: LiteLLM 1.107.0 supply chain attack · litellm on PyPI