LiteLLM 1.107.0: malicious release stole API keys and secrets

Bunch of old iron keys hanging on a wooden chest

A malicious version shipped through the official channel

LiteLLM is a popular Python library and proxy server that companies use to connect their applications to models from OpenAI, Anthropic, Google or Azure. The proxy therefore holds API keys for all of those providers. On 21 October 2026, release litellm 1.107.0 appeared on PyPI and in Docker image registries. It contained compiled malware that steals credentials and loads remote code. The release was signed and published by the project's real CI process, so from the outside it looked like an ordinary update. This is the second incident of this kind at LiteLLM this year: in March, versions 1.82.7 and 1.82.8 were malicious.

According to the LiteLLM team's initial findings, the attacker obtained GitHub CLI OAuth tokens belonging to three developers. With one, they removed branch protection and changed the release workflow; with the second, they approved publication; with the third, they deleted run records. The code for the build was pulled from the Berri-AI/litellm repository, which differs from the original BerriAI/litellm by a single hyphen. The team suspects the tokens came from the logs of an internal LiteLLM instance exposed to the internet: Claude Code can embed a user's GitHub CLI token in a response body, and if the AI gateway logs response bodies, the token ends up in the logs. How the attacker got into that instance is not confirmed; LiteLLM points to a recently patched vulnerability. No CVE has been assigned.

What the malicious code does

The package writes cook.pth, cook.py and sitecustomize.py into the site-packages directory. Python executes them every time the interpreter starts, even if no script imports LiteLLM. The malicious code collects credentials for AWS, Azure, Google Cloud, Kubernetes and Docker, Git credentials, SSH and GPG keys, browser data, shell history, authentication files for Claude, Codex, Gemini and Cursor, and provider keys from the LiteLLM proxy database. The data is encrypted and sent to an address impersonating the project's domain. On Linux and macOS, a second module runs as a background process and checks a file on GitHub every hour for an address from which to download more code.

Attack window and versions

Malicious: litellm==1.107.0 on PyPI (all seven wheel files), available on 21 October from 11:39 to 13:23 UTC.
Docker Hub: tags v1.107.0, latest, main-latest, main-stable from 11:46 to 14:20 UTC; the index digest starts with sha256:1bbcb1443bc9.
GHCR: the same tags of the litellm, litellm-database and litellm-non_root images from 11:46 to 13:51 UTC.
Safe: 1.106.2 and any explicitly pinned version released before the incident. Customers of the private Enterprise registry were not affected.

Who could have pulled it

The window lasted under three hours, so the most exposed systems are those that fetch the newest version on their own: CI pipelines installing litellm without a version number, containers running the latest or main-stable tag that were restarted in that period, and developer machines that happened to update. If you pin the version in a lockfile or pin the image digest, you were probably not hit.

How to check your environments

In every virtualenv and container: pip show litellm or pip list | grep -i litellm.
Lockfiles and requirements: grep -rn "1.107.0" requirements*.txt poetry.lock uv.lock Pipfile.lock.
Traces on the system: find / -name 'cook.pth' -o -name 'cook.py' -o -name 'litellm-1.107.0.dist-info' 2>/dev/null and unusual sitecustomize.py files in site-packages.
Background process: ls -l /tmp/remote_code_loader.lock and ps aux | grep python.
Images: docker images --digests | grep litellm compared with the digest above; CI logs from 21 October between 11:39 and 14:20 UTC.

The absence of these traces does not prove a system is clean, as the vendor itself warns.

What to do if 1.107.0 ran

Do not start with pip install in the infected environment: every Python start runs the malicious code again.
Delete the cook* and sitecustomize* files together with their .pyc files from every site-packages directory and kill the background process. It is better to rebuild the image or virtualenv from scratch with litellm==1.106.2.
If the host had internet access, assume the data leaked. Rotate all LLM provider keys stored in the proxy, the LiteLLM master key and virtual keys, the DATABASE_URL password, the instance IAM role, GitHub tokens, SSH keys and every secret in environment variables on that host.
In AWS, review CloudTrail for GetCallerIdentity calls around the install time, use of keys from outside your infrastructure and unexpected Amazon Bedrock activity. With LLM providers, check usage and billing.

AI gateway logs are a secret store too

This incident shows two things. First, a signed release from official CI does not guarantee safety, so versions and image digests must be pinned and dependency updates let through with a delay of a few days. Second, an AI gateway that logs full requests and responses collects everything that coding agents and users send through it, tokens included. Such logs need secret masking, short retention and access limited to a small group of people, and the gateway itself should not be reachable from the internet.