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. Correction, October 24: LiteLLM’s October 23 canonical report supersedes its earlier theory that tokens leaked through an internal deployment’s logs. An unrevoked Agent Platform master key exposed in May let the attacker retrieve the owner token through that service’s API on October 10; malicious CI workflows then extracted two maintainer tokens.

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 is now confirmed by the vendor: exposed master key → Agent Platform API → GitHub owner token → CI secret exfiltration. This revises the earlier unconfirmed theory.
• Tracker correction: GHSA-92x9-889m-jgmw now includes 1.107.0. Its older publication date and March entries do not establish a relationship between the attacks. Wiz and JFrog also track this incident as wiz-adv-2026-188 and XRAY-955589.
• LiteLLM mentions an embargoed enterprise fix due for disclosure on October 27; it is not clear whether it is related.

Update, November 1 (UTC): The vendor’s October 30 notice publishes the replacement cosign public-key fingerprint and says the old private key may have been exposed. The rotation happened October 23; the first releases signed with the replacement key shipped October 24. Verify the pinned key and the image digest together. The malicious images were signed by the real release pipeline with the old key, so a valid signature alone never excluded this compromise. The exposed-host rebuild and credential-rotation steps above still apply.