LiteLLM 1.107.0 shipped a credential stealer on PyPI and Docker

LiteLLM 1.107.0 shipped a credential stealer on PyPI and Docker

21 October 2026: LiteLLM, the open-source gateway many companies run in front of their language model providers, says version 1.107.0 published on 21 October on PyPI, Docker Hub and GitHub's container registry carried compiled malware that steals credentials and sets up remote code execution. The poisoned builds were live for about two hours; version 1.106.2 and everything earlier is safe, and customers on the private enterprise release were not affected.

Not yet independently verified. This rests on LiteLLM's own incident page and its 23 October attack-chain report, which replaced the first account of how the tokens leaked. It gives no CVE and no outside party has confirmed it. We will update this when it can be confirmed, and remove this note.

Update, 10 November 2026: LiteLLM has corrected its account of how the attacker got in, and the section on the release pipeline below now follows its report of 23 October. It rotated its cosign image signing key on 23 October, and an update of 30 October says the rotating commit now shows as verified on GitHub and adds the new key's fingerprint.

The windows that matter

All times are UTC on 21 October:

Where	What	Live
PyPI	litellm==1.107.0, all seven wheels	11:39:51 to 13:23
Docker Hub	v1.107.0, latest, main-latest, main-stable	11:46:56 to 14:20
GHCR	the same tags for litellm, litellm-database and litellm-non_root	11:46:56 to 13:51

Anyone who ran an unpinned pip install litellm or pulled one of those image tags in the window should treat the machine as compromised. The official v1.107.0 source tag on GitHub does not contain the malicious files: the packages were built from a repository the attacker controlled.

How the release pipeline was taken over

The attacker used three GitHub identities at LiteLLM, through stolen GitHub CLI OAuth tokens. One account overrode branch protection to change the release workflow, a second approved the production deployment gate, and a third deleted the workflow run records. LiteLLM has removed the packages from all three registries, revoked the maintainers' credentials and cut its GitHub organisation back to a single user while it investigates. LiteLLM's report of 23 October, which it calls the canonical account, replaces the explanation it gave on the day. A configuration file committed to a public repository on 27 May 2026 contained an administrative key to an internal LiteLLM Agent Platform deployment. The file was deleted about three hours later, but the key was never revoked. On 10 October the attacker used it to take control of that deployment and extract the GitHub CLI OAuth token of the GitHub organisation owner, then ran workflows that collected similar tokens from two engineers with maintainer rights, along with tokens to other internal systems. LiteLLM says it is revoking every token for every internal system and vendor platform. The poisoned workflow then signed and published from a lookalike repository, Berri-AI/litellm.

Cleaning up without re-running the malware

The order matters, because the payload starts with Python itself. LiteLLM's instructions:

• do not run pip install first; any Python start in an affected environment runs the malicious files again
• delete cook.pth, cook.py, sitecustomize.py and the matching .pyc files from every affected site-packages, and kill the detached Python process holding /tmp/remote_code_loader.lock
• reinstall pinned to litellm==1.106.2, or better, rebuild images and virtual environments from scratch
• if 1.107.0 ran with outbound internet access, assume data left the machine

Finding the indicators confirms exposure; not finding them proves nothing.

What to rotate on a gateway

A gateway holds the keys to every model provider it fronts, which makes this worse than a typical package compromise. LiteLLM lists the instance or task IAM role, every provider key stored in the proxy database, master and virtual keys, the DATABASE_URL password and any secret in the process environment, and suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time. Our AI gateways category lists two products. Monday's OVHcloud CLI incident used the same route, a trusted account publishing over a real release, and there it was a user's pinned hash that caught it first.

Sources

• LiteLLM: Security incident, 21 October 2026 (release v1.107.0 compromised), 21 October 2026
• LiteLLM: The attack chain behind the v1.107.0 release, 23 October 2026