LiteLLM supply chain attack: what to do if you installed 1.107.0

LiteLLM is a popular gateway between applications and model providers such as OpenAI, Anthropic and Google. On 21 October 2026, attackers published a malicious LiteLLM release, version 1.107.0, on PyPI and Docker Hub. The LiteLLM supply chain attack stole cloud credentials and AI API keys from each machine that installed it. If your team uses LiteLLM, check your systems today.

Which versions and images are affected

The LiteLLM incident report lists these artifacts with malware:

Channel	Affected	Time window on 21 October (UTC)
PyPI	litellm==1.107.0, all seven wheels	11:39 to 13:23
Docker Hub	tags v1.107.0, latest, main-latest, main-stable	11:46 to 14:20
GHCR	the same four tags	11:46 to 13:51

LiteLLM says that all earlier versions are safe. The official v1.107.0 source tag on GitHub does not contain the malicious files. The attack did not affect enterprise customers on the private registry.

You are at risk if an install or a container start in that window used an unpinned version or one of these tags. CI pipelines and containers that pull latest have the highest risk.

What the malware does

Datadog Security Labs analysed the release. It adds three files to site-packages: cook.pth, cook.py and sitecustomize.py. Python runs .pth files and sitecustomize.py at each interpreter start. Thus each Python process in the environment runs the malware, also when it never imports LiteLLM.

The credential stealer collects, among other things:

• AWS, GCP and Azure credentials, also from instance metadata.
• Kubernetes, Docker, Vault and Terraform secrets.
• SSH keys, Git, npm and PyPI tokens, .env files and shell history.
• LLM provider API keys and sessions of AI tools for developers, such as Claude, Codex and Cursor.
• The upstream provider credentials in the LiteLLM proxy database, if one is configured.

A second file is a backdoor. Each hour it asks a remote address for code to download and run. Datadog saw no second-stage payload at the time of its analysis. Deletion of the litellm package directory does not remove the three files.

The attacker used the stolen data fast. Help Net Security reports research from Wiz. Approximately four and a half hours after the theft, the attacker tested AWS credentials from compromised CI runners and Kubernetes nodes. The attacker also checked access to Amazon Bedrock.

How the attackers got in

The attack chain report starts with one key. On 27 May 2026, someone committed an admin key for an internal LiteLLM platform to a public repository. Nobody revoked it, and it was still valid four months later. With that key the attacker got a GitHub token of an organisation owner. Then the attacker took more tokens and pointed the release pipeline at a lookalike repository.

This is the second LiteLLM supply chain compromise of 2026. Datadog links an earlier incident in March, with versions 1.82.7 and 1.82.8, to the TeamPCP campaign. Datadog found no connection between the two attacks when it published its report.

What to do now

LiteLLM gives these steps. Do them in this order.

1. Do not start with pip install. Each Python start in an affected environment runs the malware again, also pip.
2. Search for the evidence. Look for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Also look for containers that ran the image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. No evidence does not prove that a host is clean.
3. Remove the files from the shell. Delete cook.pth, cook.py, sitecustomize.py and their .pyc files from each affected site-packages. Stop the Python daemon that holds /tmp/remote_code_loader.lock.
4. Rebuild. Build new images and virtual environments from scratch. Pin litellm==1.106.2 or another explicit earlier version.
5. Assume that the theft succeeded. Do this for each host with outbound internet access.
6. Rotate from a clean machine. Rotate the IAM role of the host, every provider key in the LiteLLM proxy database, the master and virtual keys, the database password and all secrets in the environment of the host.
7. Examine your cloud logs. In AWS CloudTrail, look for GetCallerIdentity calls near the install time. Then look for use of those credentials from outside your infrastructure.

Also do three things for the long term:

• Pin exact versions and image digests in production and CI. Do not deploy latest.
• Give the gateway its own provider keys with low spend limits. Then a stolen key costs less.
• Scan your public repositories for secrets, and revoke each key that leaks. The LiteLLM attack started with a key that nobody revoked.

How we approach this

An LLM gateway holds the keys to every model provider that you use. Thus it is a valuable target. For a financial services company we built a private AI workspace with many agents. An API layer between the agents and the model providers records the use and caches the answers. We treat such a layer as critical infrastructure, and we apply the checklist above to it.