LiteLLM 1.107.0 Was Backdoored: How to Check and Clean Up

Last updated: 24 October 2026. Sources are listed at the end.

On 21 October 2026, attackers published a backdoored LiteLLM 1.107.0 to PyPI and Docker Hub. LiteLLM is a popular Python library and proxy for calling AI models; PyPI counts about 3.3 million downloads a day. The bad release was live for less than two hours on PyPI. Even so, anyone who installed it during that window should assume their secrets are stolen. This LiteLLM 1.107.0 guide shows how to check and clean up safely.

The short answer

• Affected: litellm==1.107.0 from PyPI, and the v1.107.0, latest, main-latest and main-stable Docker images pulled during the window.
• Safe: 1.106.x and earlier. Pin litellm==1.106.2 until a new clean release is out.
• Don’t run Python first. The malware starts every time Python starts in that environment.

When was LiteLLM 1.107.0 live?

In India, that is roughly 5:10 pm to 7:50 pm IST. Also check CI jobs and auto-updating deployments that ran at that time, because they often pull latest without anyone noticing.

How the attack worked

According to LiteLLM’s incident report, attackers used stolen developer credentials to change the release workflow. The real pipeline then built the package from a lookalike repository and published it. As a result, the malicious release even carried valid provenance. The source code tag on GitHub stayed clean. This is LiteLLM’s second supply-chain incident this year.

The payload has three parts:

• cook.pth runs on every Python start, even if you never import LiteLLM.
• cook.py steals browser passwords, SSH, GPG and TLS keys, AWS, Azure, GCP, Kubernetes and Vault credentials, .env files, environment variables and configs for more than 20 AI coding tools. If DATABASE_URL is set, it also dumps the LiteLLM proxy database, including your upstream AI provider keys.
• sitecustomize.py starts a hidden process that checks every hour for new code to run.

Researchers found no second stage yet. However, the hourly loader still polls, so a cleanup is essential.

Step 1: Check without starting Python

These commands only read files, so they are safe to run. We tested them on a sample environment.

# Payload files inside any virtualenv or site-packages folder
find / -xdev \( -name 'cook.pth' -o -name 'cook.py' \) -path '*-packages*' 2>/dev/null

# Installed metadata for the bad version
find / -xdev -type d -name 'litellm-1.107.0*.dist-info' 2>/dev/null

# Marker files the malware leaves
ls -la /tmp/.pc_once_72129118c59f5636c0bb /tmp/remote_code_loader.lock 2>/dev/null

# Lockfiles and requirements in your projects
grep -rn -A2 -i 'litellm' --include='requirements*.txt' --include='*.lock' --include='pyproject.toml' . | grep '1\.107\.0'

Also look at sitecustomize.py files in site-packages. Legitimate ones exist, so read the file before you decide.

Docker

docker images --digests | grep -i litellm

The malicious multi-arch index digest starts with sha256:1bbcb1443bc9. Check deployments that follow floating tags too.

Network logs

Search proxy, firewall or DNS logs for litellm.dev. The malware posts stolen data over plain HTTP to www.litellm.dev/healthcheck, a domain registered on 13 October. In AWS, look in CloudTrail for GetCallerIdentity calls from your instance role around the install time.

Step 2: Clean up

1. Isolate the machine or container. Then stop the hidden loader process that holds /tmp/remote_code_loader.lock.
2. Delete the payload files and the litellm-1.107.0 package folder. Better still, delete the whole virtualenv or container.
3. Rebuild from scratch with litellm==1.106.2 pinned, and use a lockfile with hashes.
4. Purge cached copies, such as the pip cache (pip cache remove litellm) and old images in your registry.

Step 3: Rotate every secret the machine could read

This step matters most. Assume an attacker has everything below:

• AI provider keys (OpenAI, Anthropic, Azure OpenAI, Bedrock and others), including every key stored in the LiteLLM proxy database
• LiteLLM master and virtual keys, and the database password in DATABASE_URL
• Cloud credentials, including the instance or task IAM role
• SSH and GPG keys, Kubernetes configs, Vault tokens, and anything in .env files
• Passwords saved in browsers on developer laptops

Afterwards, watch your AI provider bills and usage dashboards. Stolen AI keys are often resold for “LLMjacking”, and the first sign is a spike in spend.

Lessons for every team

• Pin versions with hashes. A lockfile with hashes would have refused a surprise new release.
• Don’t auto-deploy latest. Use tested, pinned tags.
• Wait a day before taking new releases of critical dependencies, unless they fix a security issue.
• Keep secrets out of build machines where possible, and use short-lived credentials.

The same week saw other supply-chain attacks on developer tools. Read our guide to the OVHcloud CLI and Railway incidents and our Black October fact-check. If you want a review of your build pipeline and secrets handling, see our VAPT services.

Sources

• LiteLLM: security incident report, 21 October 2026
• StepSecurity: LiteLLM 1.107.0 backdoored wheels
• Socket: LiteLLM compromise analysis
• Help Net Security: LiteLLM supply-chain attack
• PyPI Stats: litellm downloads

Want a second pair of eyes on your DevOps security? Our VAPT services cover CI/CD pipelines, self-hosted tools and how secrets are stored. For servers, see our Linux server hardening & security audit, or contact us.