Supply Chain · Breaking

LiteLLM 1.107.0 shipped a credential stealer on PyPI and in the official Docker images, including latest, and it goes straight for the AI gateway’s stored provider keys

Anyone who installed litellm 1.107.0 or pulled the latest, main-latest or main-stable image this morning should treat that host as compromised. The release carried a stealer that dumps cloud, CI, browser and AI-tool secrets, plus the provider API keys stored in the LiteLLM proxy database. It ran on every Python start, without anyone importing litellm. Safe version: 1.106.2.

Oct 21, 2026 · 3 min read

What happened. Per Wiz and StepSecurity, litellm 1.107.0 hit PyPI at 11:39 UTC (4:39 AM PT) Oct 21 and was gone by about 13:23 UTC (6:23 AM PT). The same payload was in the official images on GHCR and Docker Hub (litellm, litellm-database, litellm-non_root). Between about 11:48 and 14:32 UTC (4:48 to 7:32 AM PT), the floating latest, main-latest and main-stable tags pointed at the infected build, so proxies that restarted or re-pulled in that window picked it up. A user reported it in BerriAI/litellm issue #47826 at 12:06 UTC. This is the second LiteLLM PyPI compromise this year, after 1.82.7/1.82.8 in March (per StepSecurity).

How it got in. The git tag is clean. StepSecurity says the SLSA provenance on the bad images shows BerriAI’s own release workflow building from a lookalike repo, github.com/Berri-AI/litellm (note the hyphen). There, ten commits added three files and one line, data = "cook", under [tool.maturin] in pyproject.toml, which bundled the malware into the wheels. The lookalike exfil domain litellm.dev was registered Oct 13. How the release job ended up pointed at the fork is still Undisclosed; BerriAI says it is investigating. BerriAI says its private enterprise registry wasn’t affected (per StepSecurity).

What it takes. The wheel drops cook.pth, cook.py and sitecustomize.py into site-packages, so the payload runs every time Python starts. The stealer, which calls itself privcollect, runs 16 modules covering browser passwords and cookies, SSH/GPG/TLS keys, AWS/GCP/Azure creds including instance-metadata role tokens, kubeconfig, Vault and CI secrets, every readable process environment, and configs for 20+ AI coding tools. If DATABASE_URL is set, it queries LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, which is where every upstream OpenAI, Anthropic, Azure, Bedrock and Vertex key a gateway holds lives. Output is AES-256 plus RSA-4096 encrypted and POSTed to www.litellm[.]dev/healthcheck. A second daemon polls a GitHub dead drop every hour for code to run. Per StepSecurity, that dead drop was never armed before GitHub took it down. Victim count: Undisclosed.

The buyer angle. The AI gateway has quietly become the most valuable key vault in a lot of companies, because it holds every model provider credential in one database. Pinning by tag isn’t enough when the tag itself gets repointed. This is the argument for digest-pinned images, an internal package proxy that can block a version org-wide, and egress allowlists on CI and gateway hosts. It also reopens the open-source-gateway vs managed-gateway debate that procurement teams were already having.

What we’d do now. Search lockfiles and image digests for 1.107.0 and any Oct 21 pulls of the floating tags. On hits: kill whatever holds /tmp/remote_code_loader.lock, delete the three files, redeploy on v1.106.2 by digest, and purge 1.107.0 from internal mirrors and pull-through caches, since some PyPI mirrors kept serving it. Then rotate everything the host could reach, starting with every provider key in the proxy DB and the LiteLLM master and salt keys. Block litellm.dev and alert on raw.githubusercontent.com/letters9813/ and any path ending in /codepy.

Sources