LiteLLM, round two: your LLM gateway now proxies your keys to someone else

LiteLLM is the Python SDK and proxy that sits between apps and dozens of LLM providers, so it tends to run with every provider key a company has. On October 21, 2026 a malicious litellm==1.107.0 landed on PyPI at 11:39 UTC, and the official Docker images under the v1.107.0, latest, main-latest and main-stable tags pointed at a poisoned build from 11:46 UTC. This is LiteLLM’s second release-pipeline compromise this year, after 1.82.7 and 1.82.8 in March. JFrog and Datadog say nothing links the two so far.

How it got out

According to LiteLLM’s own report, the attacker held GitHub CLI OAuth tokens belonging to three engineers. One belonged to an organization owner and was used to override branch protection on the private release workflow and point it at Berri-AI/litellm, a lookalike repo one hyphen away from the real BerriAI/litellm. A second token passed the production approval gate, and a third deleted the workflow run records afterwards. The real v1.107.0 git tag is clean. The artifacts were built from the attacker’s copy and signed by the real pipeline. LiteLLM suspects the tokens leaked through an internet-exposed internal deployment, possibly via a recently patched bug, but has not confirmed the initial access.

What the payload does

All seven 1.107.0 wheels carry three extra files: cook.pth, cook.py and sitecustomize.py. The source distribution does not. Because of the .pth hook, the stealer runs at every Python start in that environment, even if nothing imports LiteLLM and even when you run pip. Per Socket and JFrog it collects:

• cloud credentials (AWS, Azure, GCP), instance-metadata tokens, and an STS GetCallerIdentity check
• Kubernetes, Docker, Vault, Terraform and CI secrets; SSH, GPG and TLS keys; git, npm and PyPI configs
• AI tool credentials (Claude, Codex, Gemini, Cursor, Copilot, Hugging Face and others)
• browser databases, shell history, and every readable process environment on Linux
• if DATABASE_URL is set, the LiteLLM proxy’s own LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, which hold your provider keys

The data is encrypted (AES-256 with an RSA-4096-wrapped key) and POSTed to www.litellm[.]dev/healthcheck. sitecustomize.py also forks a detached daemon that checks a GitHub dead drop every hour for a domain, then downloads and exec()s Python from it with no integrity check. The dead drop was empty when researchers looked and has since been removed, but the stealer part does not depend on it.

Is it being used?

Yes. Wiz observed stolen AWS instance-role credentials being validated from 168.100.8.57 and 165.227.201.8 roughly 4.5 hours after exfiltration, and IAM enumeration in “a small number” of environments. Datadog reports no second-stage payload seen in the wild. No source gives a download count for 1.107.0; the only figure cited is LiteLLM’s ~23 million weekly downloads overall, which is not the exposure.

Why L4

A package that by design holds every LLM provider key, a payload that steals cloud and AI credentials on any Python start, and confirmed attacker use of stolen credentials: that is active exploitation with mass credential theft. It stays below L5 because it was a single release live for about two hours, not self-propagating, and no core runtime or trust anchor broke.

What’s still unclear

• Exact windows. LiteLLM says PyPI removal at 13:23 and Docker Hub cleaned by 14:20 UTC; Wiz and Datadog say 13:20 and ~13:53; the GitHub issue reported Docker tags still bad at 13:23 and yanked by 17:13. If you pulled a floating tag anywhere in that afternoon, check the digest.
• Initial access to the engineers’ tokens is suspected, not confirmed.
• No GHSA or CVE has been issued yet. Wiz tracks it as wiz-adv-2026-188, JFrog as XRAY-955589.
• LiteLLM mentions an embargoed enterprise fix due for disclosure on October 27; it is not clear whether it is related.