LiteLLM hijacked: poisoned PyPI and Docker release planted credential-stealing malware in popular AI gateway

LiteLLM, a widely used open-source gateway for calling AI models from many providers, was hit by a supply chain attack on 21 October 2026. Attackers published a malicious version 1.107.0 to PyPI and pushed compromised Docker images, according to LiteLLM's incident report.

How long were the malicious packages live? #

LiteLLM says the official GitHub v1.107.0 source tag did not contain the malicious files, because the artifacts were built from an attacker-controlled repository. Enterprise customers using its private registry were not affected.

How did attackers get in? #

LiteLLM says three engineers' GitHub accounts were used, which "appear[s] to be" the result of stolen GitHub CLI OAuth tokens. One account changed the release workflow, another approved the production release, and a third deleted workflow records to hinder the investigation. LiteLLM says it has not yet found how the tokens were obtained.

What does the malware do? #

The package drops cook.pth, cook.py and sitecustomize.py into Python's site-packages, so the malware runs every time Python starts. According to Wiz, it steals:

• AWS, Google Cloud and Azure credentials
• AI provider API keys
• SSH and GPG keys, browser data and shell history
• The LiteLLM proxy's stored database credentials

Wiz says the data was encrypted and sent to a lookalike domain, litellm[.]dev, and that it saw stolen credentials being used about four and a half hours after exfiltration. LiteLLM says the package also runs a detached Python daemon with remote code execution capability.

What should LiteLLM users do? #

1. Check whether pip show litellm reports 1.107.0, or whether you pulled any of the affected Docker tags during the windows above.
2. Do not run pip install first in an affected environment, because Python startup re-runs the malware. Delete cook.pth, cook.py, sitecustomize.py and matching .pyc files, and kill the daemon holding /tmp/remote_code_loader.lock.
3. Rebuild environments and images from scratch, pinned to litellm==1.106.2 or another version published before the incident.
4. If 1.107.0 ran on a host with internet access, assume data was stolen. Rotate the host's cloud IAM role, every provider key stored in the LiteLLM proxy, master and virtual keys, the DATABASE_URL password and any secret in the host's environment.
5. Check cloud logs, such as AWS CloudTrail, for GetCallerIdentity calls around install time and for use of those credentials from outside your infrastructure.