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, which was still being updated; it gives no CVE, and how the GitHub tokens were stolen is not yet known. We will update this when it can be confirmed, and remove this note.

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 the GitHub accounts of three LiteLLM engineers, apparently 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. It has not yet found how the tokens were stolen.

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.

Related on TrustList:

• SAP patches a CVSS 10 token flaw in its Cloud SDK for Python
• Exploit attempts hit Langflow flaw that runs any command via MCP
• MCP Python SDK clients could hand OAuth secrets to a hostile server: upgrade to 1.30.0 or 2.2.0 and set the issuer

Sources

• LiteLLM: Security incident, 21 October 2026 (release v1.107.0 compromised), 21 October 2026