LiteLLM 1.107.0 was malware: if you pulled latest, rotate your keys

LiteLLM is a gateway that puts many model providers behind one API. On 21 October 2026 someone published a tampered version 1.107.0 on PyPI and as a Docker image. It reads out credentials and sends them to a foreign server. You are affected if you installed that version in the window, or pulled a tag such as latest. This post separates what several independent sources confirm, what only LiteLLM itself says, and what we infer from it.

Time window on 21 October 2026

Verified (LiteLLM and Datadog agree): only 1.107.0 is affected, and 1.106.2 is the last safe version. On PyPI, all seven wheels were up from 11:39:51 to 13:23 UTC according to LiteLLM. Datadog puts the quarantine at 13:20.

Vendor-claimed (LiteLLM): the Docker tags v1.107.0, latest, main-latest and main-stable pointed to a tampered image from 11:46:56 to 14:20 UTC. On GHCR the same tags were unreachable until 13:51, says LiteLLM. Datadog gives 13:53 as the removal time. If you want to be safe, plan with the widest window.

What the malware does

The package brings the files cook.pth and cook.py (stealer) and sitecustomize.py (remote access) into site-packages. A .pth file is executed when the interpreter starts. Datadog writes that every Python process in the environment runs the malware, even if LiteLLM is never imported.

Datadog and The Register (verified) report that the stealer collects:

• Cloud credentials for AWS, GCP and Azure
• Secrets from Kubernetes, Docker, Vault and Terraform
• SSH and GPG keys, .env files, shell history
• API keys of LLM providers, including the provider keys in the proxy database

The Register describes the exfiltration: the data is encrypted with AES-256-CBC, the key is wrapped with RSA-4096, then a POST goes to www[.]litellm[.]dev/healthcheck. That is a lookalike domain.

Vendor-claimed: the official source on GitHub does not contain the malware. The artifacts were built from a repository with an almost identical name (Berri-AI/litellm, with a hyphen). The Register and Datadog also describe the lookalike repository.

Datadog also observed that the remote-access component polls a file in a GitHub repository every hour, which names a domain from which code would be fetched and run. That file held only test values, and no second stage showed up in the wild. This is Datadog's statement about its observation period, not a guarantee for the future.

How it happened (vendor account)

In its report of 23 October, LiteLLM names stolen GitHub CLI tokens of three accounts (one organization owner, two maintainers) as the cause. The first token reportedly came from an agent-platform master key that ended up in a public repository on 27 May and was never revoked. The first report had suspected internal deployment logs and was corrected. This chain comes from the vendor alone.

It is the second incident at LiteLLM this year: earlier this year, versions 1.82.7 and 1.82.8 were tampered with (Datadog gives no month). Datadog writes that no connection had been established at the time of its report. So we keep the two cases separate. On scale, The Register cites about 23 million downloads per week (The Register's figure, take it as an order of magnitude only).

Check: were we in the window?

1. Compare versions. pip show litellm inside the container or environment, docker image ls --digests on the host. Compare version 1.107.0 and the index digest that LiteLLM lists in its report.
2. Look at the time range. Pull logs, CI runs and image history from 21 October between 11:39 and 14:20 UTC.
3. Search for indicators. /tmp/.pc_once_* (according to The Register a sign that the exfiltration already ran) and /tmp/remote_code_loader.lock. Also cook.pth and cook.py anywhere on the file system. LiteLLM points out that missing traces do not prove the environment is clean.

Inferred from the tag times: anyone pulling latest today no longer gets the malicious image, because the tags were reset by 14:20 UTC at the latest. At risk are pulls inside the window and environments that have run unchanged since.

If you have a hit

Rebuild the affected environment. Deleting the LiteLLM directory does not remove the payload, and every call to python or pip triggers it again (Datadog and LiteLLM). The procedure the vendor recommends:

1. Isolate the host and stop any running malware daemons.
2. Remove cook.pth, cook.py and sitecustomize.py, or better, rebuild the environment completely.
3. Rotate from a clean machine: the instance's IAM role, every provider key in the proxy database, master and virtual keys, the password in DATABASE_URL and every secret that was set as an environment variable.
4. Search CloudTrail for GetCallerIdentity calls (LiteLLM's recommendation).

Our own state

On 24 October 2026 we looked read-only and changed nothing. The host that runs our chat frontend and the LiteLLM router runs ghcr.io/berriai/litellm:v1.100.4, image built on 3 October, container last started on 20 October, and litellm-1.100.4 is installed inside it. The host of the TMS interface runs v1.106.1. That container was created on 21 October at 06:44 UTC, about five hours before the first malicious upload at 11:39.

Neither container has /tmp/.pc_once_* or /tmp/remote_code_loader.lock, and find over the container file systems turned up no cook.pth and no cook.py. A sitecustomize.py exists only inside the ddtrace and opentelemetry packages; there is none in the root of site-packages. Both instances use fixed tags instead of latest. We did not check the /tmp of the hosts themselves. Result: no finding, both instances were outside the window.

What you can change

Use fixed tags or digests instead of latest and main-*; they are the insurance that worked in this incident. The gateway should reach only the destinations it needs, because exfiltration fails against an egress block. Keep provider keys narrowly scoped and budgeted in the database so a theft stays contained. Adopt new versions only after a few days of waiting: this one was blocked after roughly two hours.

Further sources

• LiteLLM: Security Incident, 21 October 2026: timeline, digests, rotation list (vendor)
• LiteLLM: Attack Chain: cause according to the vendor, correction of 23 October
• Datadog Security Labs: LiteLLM compromised on PyPI and Docker: payload, time window, cleanup
• The Register: LiteLLM supply chain attack hoovers up passwords and secrets: encryption, destination, indicators
• Simple Icons: pypi.svg and docker.svg: logos, CC0
• Our own check on 24 October 2026 (read-only, see section Our own state): versions, image dates, file search inside the containers