LiteLLM 1.107.0 Was Hijacked: How to Check Your Machine

If you installed LiteLLM on October 21, your API keys might already be gone. One of the most popular AI libraries shipped a release with a credential stealer inside it. Here's what happened and what to do about it today.

What happened

On the morning of October 21, 2026, litellm version 1.107.0 was published to PyPI with compiled malware in it. LiteLLM's own incident post says the release "contained compiled malware which steals credentials and loads remote-code execution tools."

The windows, all in UTC on October 21:

• PyPI: the seven 1.107.0 wheels were live from 11:39 to 13:23, about an hour and 45 minutes.
• Docker Hub: the v1.107.0, latest, main-latest and main-stable tags pointed to compromised images from 11:46 to 14:20.
• GHCR: the same tags were compromised from 11:46 until they became unavailable by 13:51.

The official GitHub v1.107.0 tag never had the malicious files. The attacker ran LiteLLM's release workflow against a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm, and that build is what got signed and published. LiteLLM says every earlier version is safe and recommends pinning to 1.106.2.

SafeDep's analysis of the payload is the scary part. The stealer collects SSH keys, cloud credentials for AWS, Azure, gcloud and Kubernetes, AI tool configs such as Claude Code, Cursor and Codex auth files, and the LLM provider keys stored in a LiteLLM proxy database. A background daemon then checks a GitHub file every hour for a server address, reruns the stealer, and downloads and executes more code from that server.

The infection lives in three files the wheel drops into site-packages: cook.pth, cook.py and sitecustomize.py. Python runs them on every start, even if you never import LiteLLM. That includes running pip.

One honest caveat: LiteLLM added an October 23 update saying some of its earlier assumptions about the attack were inaccurate or incomplete, and it points to a separate attack-chain write-up as the canonical record. Read that one before you rely on the root-cause details.

Why it matters for builders

LiteLLM sits in the middle of a lot of AI stacks. It's the layer that holds every provider key you have. A compromised release of a library like that hands an attacker your OpenAI, Anthropic and cloud credentials in one shot.

The other lesson is how fast this moved. Most teams install latest in CI and never look again. If your pipeline ran during that window, it pulled the bad version automatically. Pinning versions and locking hashes would have blocked it.

Check your machine in 15 minutes

Do these in order. Use your shell for the checks, because any Python process, including pip, can trigger the malware on an infected environment.

1. Search your lockfiles and requirements for the bad version: grep -rn "litellm.*1\.107\.0" --include="*.txt" --include="*.lock" --include="*.toml" .
2. Look for the planted files without starting Python: find / -name "cook.pth" -o -name "cook.py" 2>/dev/null. Also check any sitecustomize.py that turns up inside a site-packages folder you didn't put there yourself.
3. Check for the daemon's lock file: ls -la /tmp/remote_code_loader.lock. LiteLLM says a detached Python process holds it.
4. For Docker, compare your image digest against the compromised index LiteLLM published: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.
5. If you find anything: delete the three files and their .pyc copies, kill the detached Python daemon, then rebuild the environment or image from scratch pinned to litellm==1.106.2.
6. Rotate every credential the host could reach: provider keys in the proxy database, LiteLLM master and virtual keys, the database password, the instance IAM role, and anything in the environment.
7. On AWS, search CloudTrail for GetCallerIdentity calls from the instance role around install time, and for that role's credentials being used from outside your infrastructure.

LiteLLM is clear that finding the files confirms exposure, and not finding them proves nothing. If 1.107.0 ran on a host with outbound internet, assume the keys left.

Here's how you get paid

My opinion: most AI teams have never checked what their packages can touch. They know which model they call. They have no idea which of their dependencies can read the folder where their keys live.

That's a service. I'd call it an AI supply-chain check, and I'd sell it as a fixed-scope engagement:

• Inventory every package in the AI stack and flag anything installed from latest.
• Pin versions and turn on hash checking in CI.
• Move provider keys out of plain environment files and scope each key to the smallest job it needs.
• Write the incident runbook in advance, using LiteLLM's steps above as the template.
• Offer a monthly re-check as a retainer, because new versions ship every week.

The pitch writes itself right now. Every engineering lead has seen this story, and every one of them is wondering if their team would have caught it.