LiteLLM 1.107.0 was backdoored on PyPI and Docker to steal cloud and AI API keys. How to check every client and what to rotate.
On October 21, 2026, a Python package began stealing cloud and AI keys from machines where nobody had ever called it. The package was LiteLLM 1.107.0, and once installed, all it needed was for Python to start.
v1.107.0, latest, main-latest and main-stable served it from 11:46 to 14:20 UTC, per LiteLLM's timeline. Internal mirrors and caches may still hold copies.litellm==1.106.2 instead of just uninstalling, and rotate every credential the host could reach, Datadog advises.Attackers hijacked LiteLLM's release pipeline on October 21, 2026, and used it to publish a signed, malicious LiteLLM 1.107.0. LiteLLM is an open-source AI gateway: a single proxy in front of OpenAI, Anthropic, AWS Bedrock and other model providers, holding the API keys for all of them. Socket counts about 23M weekly downloads, according to Rescana.
LiteLLM's timeline shows three stolen developer credentials doing three jobs:
The build pulled its code from Berri-AI/litellm, which is one hyphen away from the real BerriAI/litellm.
This is LiteLLM's second compromise of 2026, after malicious versions 1.82.7 and 1.82.8 in March, Datadog notes. The release has no CVE or GitHub advisory, so it has no CISA KEV entry either.
The malicious package drops cook.pth, cook.py and sitecustomize.py into site-packages. Python runs both kinds of file at every interpreter start, even if nothing imports LiteLLM. Think of a note taped inside the front door that every visitor reads on the way in.
www.litellm[.]dev/healthcheck, a lookalike domain the attacker controls:The stolen keys were used. From 16:20 to 17:01 UTC, the attacker tested AWS instance-role credentials taken from CI runners and Kubernetes nodes. Each test ran sts:GetCallerIdentity and then bedrock:ListFoundationModels.
Treat a client as affected if any host, container, CI job or mirror holds LiteLLM 1.107.0 or one of the bad image digests, whenever it was fetched. The sources disagree on the removal times. Wiz and Datadog put PyPI's quarantine at 13:20 UTC and the Docker removal around 13:53 UTC, but LiteLLM's windows run to 13:23 and 14:20 UTC. The checks below use LiteLLM's wider windows.
The public registries no longer serve the malicious version, but internal mirrors (Artifactory, Nexus, devpi, registry pull-through caches) and pip and uv wheel caches keep what they fetched. Any of them can still hand 1.107.0 to a fresh build. Images built FROM a LiteLLM tag on October 21 have their own digests, so check them with the file check or rebuild them.
Don't run python or pip on a suspect host. Either one fires the malware again. Use these commands instead:
find / \( -path /proc -o -path /sys \) -prune -o \( -name cook.pth -o -name 'litellm-1.107.0.dist-info' \) -print 2>/dev/null. Then run ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock. If the first file exists, the stealer has already run. On Windows: Get-ChildItem C:\ -Recurse -Force -Filter cook.pth -ErrorAction SilentlyContinue.grep -rnE --exclude-dir=proc --exclude-dir=sys --include='requirements*.txt' --include='pyproject.toml' 'litellm[^0-9]{0,12}1\.107\.0' / 2>/dev/null. For Poetry and uv lockfiles, run grep -rn -A1 --exclude-dir=proc --include='*.lock' 'name = "litellm"' / 2>/dev/null | grep '1\.107\.0'.P='1bbcb1443bc9|c00f9d92c427|7b00e91cd2fe|bd1aeee419ea|56b74573eed6|24581ddc3076|827dd893c74c|645a67d81062|f75c8edae59b'. Then run docker image inspect --format '{{.RepoDigests}}' $(docker image ls -q) | grep -E "$P". On Kubernetes, run kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.name} {.status.containerStatuses[*].imageID}{"\n"}{end}' | grep -E "$P". Run the same pattern against each client's registry mirror.docker run --rm --entrypoint find <image> / -name cook.pth.litellm-1.107.0 and delete it. Compare cached files with the seven wheel hashes Aikido lists.~/.cache/pip and ~/.cache/uv, and clear CI caches on runners that installed LiteLLM on October 21.litellm.dev and the header X-Token: XWiA8gZNa7NcX2XRoAEb.sourceIPAddress 168.100.8.57 or 165.227.201.8, for example: aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ListFoundationModels --start-time 2026-10-21T11:00:00Z.Indicators come from LiteLLM, Wiz, Datadog and Aikido. The platform digests and the two IPs appear only in Wiz's report. A clean result is not proof, LiteLLM warns, because restarting a container or clearing /tmp wipes the evidence.
Rebuild instead of uninstalling, because the malware lives outside the LiteLLM package. From LiteLLM's remediation steps:
kill $(lsof -t /tmp/remote_code_loader.lock).litellm==1.106.2, and pin images by digest, never by latest.DATABASE_URL passwordlitellm.dev at egress.No pentest stops a signed package that arrives through a trusted pipeline. What a pentest can catch is the confirmed standing risk: self-hosted AI gateways that anyone on the internet can reach. LiteLLM's proxy alone has had three flaws added to CISA's exploited list this year, including the CVSS 9.3 SQL injection CVE-2026-42208 in May and the MCP authentication bypass CVE-2026-59822 in September. If LiteLLM's theory holds, an exposed gateway also started this incident.
KinoSec runs autonomous pentests against every client's web apps and external network. It finds exposed gateways and admin panels and tests whether an outsider can get in. On a schedule, the AI tool that someone exposed last month shows up in a report you can hand your client.
LiteLLM 1.107.0 is a malicious release of the open-source LiteLLM AI gateway. It was published to PyPI, Docker Hub and GHCR on October 21, 2026, through LiteLLM's hijacked release pipeline. It installs cook.pth, cook.py and sitecustomize.py, which steal cloud, SSH, CI/CD and AI provider credentials and add an hourly remote-code loader.
Don't start Python or pip on a suspect host. First, search every host and container for cook.pth or litellm-1.107.0.dist-info, and for /tmp/.pc_once_72129118c59f5636c0bb. Next, compare image digests with the ones LiteLLM and Wiz published. Finally, search internal package mirrors and wheel caches for litellm-1.107.0.
No. The .pth and sitecustomize.py files sit outside the LiteLLM package, so they survive pip uninstall and run at every Python start. Rebuild the environment on litellm==1.106.2. Then rotate every credential the host could reach, including the provider keys stored in the LiteLLM proxy database.
An AI gateway holds API keys for every model provider a company uses, and it usually runs next to cloud credentials. Stolen keys can be resold or used to run expensive models on the victim's bill, a practice known as LLMjacking. Exposed LiteLLM proxies were already being attacked through CVE-2026-42208 and CVE-2026-59822 before this release.