LiteLLM 1.107.0 was compromised. Here's what it means if you use it
Short answer: On October 21, 2026, litellm==1.107.0 on PyPI and the v1.107.0, latest, main-latest and main-stable Docker images carried a credential stealer. It was live for about two hours (11:39 to 13:20 UTC on PyPI, images pulled by 13:53). If you installed or pulled any of those in that window, treat every secret on that machine as stolen. That includes the provider API keys in your LiteLLM proxy database. Rotate them from a clean machine.
This is LiteLLM's second supply-chain compromise this year. In March, versions 1.82.7 and 1.82.8 were malicious. Datadog says no link between the two incidents has been established.
What happened
According to LiteLLM's own analysis, as summarized by Datadog, attackers used stolen GitHub CLI OAuth tokens from three engineers. They ran LiteLLM's private release workflow against a lookalike fork, Berri-AI/litellm (note the hyphen; the real repo is BerriAI/litellm), approved the run themselves, and then deleted the evidence. How the tokens were first stolen was not known at publication.
Why "I never imported it" doesn't help
The release dropped three files into site-packages: cook.pth, cook.py and sitecustomize.py. Python runs .pth files and sitecustomize.py automatically every time the interpreter starts. As Datadog puts it: "Any Python process in the environment runs the malware, even if LiteLLM is never imported."
So a CI job, a notebook, or a script that only happened to share a virtualenv or image with litellm was enough.
What it went after
According to Datadog and Microsoft, the stealer collected:
- LLM provider API keys. If a LiteLLM proxy database was configured, it also queried the tables that hold your upstream provider credentials and model configuration.
- Cloud credentials: AWS, GCP, Azure, Kubernetes service-account files, Docker, Vault and Terraform.
- Developer secrets: SSH, GPG and TLS keys, Git, npm and PyPI tokens,
.envfiles and shell history. - AI-tool credentials and sessions, plus browser passwords and cookies.
Collected data was encrypted and POSTed to www.litellm[.]dev/healthcheck. A second loader checked a GitHub-hosted domain.txt file hourly for a domain to fetch more code from. No second-stage payload was observed.
A gateway is a uniquely bad place to get hit. Its whole job is to hold every provider key a team has, so one compromised host exposes all of them at once.
Am I affected?
You may be affected if any of these happened between 11:39 and 13:53 UTC on October 21:
pip install litellmorpip install -U litellmwith no version pin- a build that resolved
litellm>=…and picked up 1.107.0 - a pull of
ghcr.io/berriai/litellmor the Docker Hub image bylatest,main-latest,main-stableorv1.107.0 - a cache, mirror or base image that captured any of the above, which keeps the risk alive after the window closed
Check from a clean machine, or with shell tools only. Microsoft and Datadog both warn that running Python or pip in a suspect environment can trigger the payload again. These commands use only find and ls, so they never start Python:
# startup files the release dropped, in any virtualenv or system site-packages
find / -path '*site-packages*' \( -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \) 2>/dev/null
# marker files the payload writes
ls -la /tmp/remote_code_loader.lock /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null
# installed litellm version, read from package metadata on disk
find / -path '*site-packages/litellm-*.dist-info' -maxdepth 8 2>/dev/nullA sitecustomize.py can be legitimate, so read any hit before deleting it. A litellm-1.107.0.dist-info directory is the clearest sign.
Look for:
cook.pth,cook.pyorsitecustomize.pyinsite-packages/tmp/remote_code_loader.lockor/tmp/.pc_once_72129118c59f5636c0bb- outbound traffic to
litellm[.]dev, or requests carrying the headerX-Token: XWiA8gZNa7NcX2XRoAEb
Compare wheel and image hashes against the IOC tables in the Microsoft and Datadog write-ups.
What to do
- Isolate the affected hosts, containers and runners.
- Rebuild from verified artifacts rather than cleaning in place. Microsoft: "Removing the package or a release tag is not sufficient recovery." If you must stay on LiteLLM, Datadog's guidance is to go back to
litellm==1.106.2. - Rotate, from a clean machine, every credential the environment could read. Start with the provider keys stored in the proxy, then cloud, Git and package-registry tokens.
- Revoke sessions and review provider dashboards and cloud logs for use you don't recognize. A burst of model usage is often the first visible sign of a stolen LLM key.
- Pin by hash and digest from now on. Use
pip install --require-hashesand pull images by@sha256:digest, not by a mutable tag. Restrict outbound traffic from gateway hosts to the provider endpoints they actually call.
The broader lesson for anyone running a gateway
Any self-hosted gateway concentrates keys, and any package you install with an unpinned version is a release pipeline you are trusting with them. Whatever you run, three questions are worth asking:
- Where do provider keys live, and in what form? Plaintext in a database or a config file means one host compromise exposes all of them.
- What runs on every update? Unpinned installs and mutable image tags execute whatever was published most recently.
- Can the operator read your keys? If the operator can, so can anyone who compromises the operator.
How OpenLLM answers these, plainly:
- API keys are encrypted in your browser (AES-256-GCM, under a key derived from a recovery phrase only you hold) and stored as ciphertext. They are decrypted only in memory, per request.
- Subscription logins never leave your machine. They run through the vendor's own CLI on your device.
- OpenLLM is also software you install, and its update path is a trust decision too. Its binary releases are published with committed digests that CI verifies against the released assets.
None of that makes any tool immune. It changes what one compromised host can give away.