Malware · October 23, 2026 · 3 min read

A malicious LiteLLM release stole credentials for about two hours

Version 1.107.0 on PyPI and the official Docker tags ran a stealer every time Python started. Pin 1.106.2, and don’t use pip to clean an infected environment.

BBrody · Frame

A package outline on black, three small files inside it, and one steel line leaving the box.

On October 21, 2026, attackers published LiteLLM 1.107.0, a poisoned copy of a widely used library for talking to language models. LiteLLM says the bad PyPI wheels were online from 11:39 to 13:23 UTC, and that the matching Docker tags on Docker Hub stayed up until 14:20 UTC. If you did not install or run 1.107.0 in that window, this did not land on your machine.

What was published

LiteLLM’s incident note says stolen GitHub credentials were used to run the project’s normal release process against an attacker-controlled repository. The official git tag for 1.107.0 does not contain the malicious files. The published wheels and images did.

Datadog Security Labs says the package sees about 23 million downloads a week, and that this is the second LiteLLM supply-chain compromise of 2026. Datadog says it has not established a connection between the two. It also says the release was built from a fork named Berri-AI/litellm, one hyphen away from the real BerriAI/litellm project, and that the build record showed that fork as the source.

The wheels install three extra files at the root of site-packages: cook.pth, cook.py, and sitecustomize.py. Python runs that kind of file when the interpreter starts, even if the program never imports LiteLLM. Datadog says the stealer collects cloud credentials, Kubernetes and Terraform secrets, SSH keys, package-registry tokens, language-model API keys, and saved browser passwords, then sends them encrypted to a lookalike domain. A second file checks hourly for a follow-up download. LiteLLM says that pointer only ever held test values, so no second-stage program was seen in the wild.

LiteLLM says its private registry for enterprise customers was not part of this release. PyPI, Docker Hub, and GHCR have removed the bad artifacts. The tags to watch are v1.107.0, latest, main-latest, and main-stable on ghcr.io/berriai/litellm and the related database and non-root images, plus the same tags on Docker Hub, if they were pulled in that window.

If you might have installed it

Don’t start with pip or python. Both will run the dropped files again. From a shell, delete cook.pth, cook.py, sitecustomize.py, and the matching files under __pycache__, in every affected site-packages. LiteLLM also says to stop the background process that holds /tmp/remote_code_loader.lock. Rebuilding the virtualenv or the image from scratch is the cleaner path.
Pin a release from before the incident. LiteLLM’s current instruction is litellm==1.106.2, or any explicit version published before this one. A floating latest tag is how the bad image was delivered.
Rotate secrets the host could see. If 1.107.0 ran on a machine with outbound internet, LiteLLM says to assume the theft worked. That includes cloud role credentials, keys stored in a LiteLLM proxy database, the database password, and anything in the environment of a process on that host. A missing marker file does not prove the theft failed. Containers and temp cleanup remove it.
A copy installed before 11:39 UTC, or only from source at the real git tag, is outside this incident. The malicious files were in the published artifacts, not in that tag.

Sources

LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 compromised, October 21, 2026
Datadog Security Labs, LiteLLM supply chain compromise: What you need to know, October 21, 2026

New posts, by email.

About once a month. Plain-language privacy notes, nothing else. I never share your address.

What was published

If you might have installed it

Don’t start with pip or python. Both will run the dropped files again. From a shell, delete cook.pth, cook.py, sitecustomize.py, and the matching files under __pycache__, in every affected site-packages. LiteLLM also says to stop the background process that holds /tmp/remote_code_loader.lock. Rebuilding the virtualenv or the image from scratch is the cleaner path.

Pin a release from before the incident. LiteLLM’s current instruction is litellm==1.106.2, or any explicit version published before this one. A floating latest tag is how the bad image was delivered.

Rotate secrets the host could see. If 1.107.0 ran on a machine with outbound internet, LiteLLM says to assume the theft worked. That includes cloud role credentials, keys stored in a LiteLLM proxy database, the database password, and anything in the environment of a process on that host. A missing marker file does not prove the theft failed. Containers and temp cleanup remove it.

A copy installed before 11:39 UTC, or only from source at the real git tag, is outside this incident. The malicious files were in the published artifacts, not in that tag.