LiteLLM 1.107.0 was compromised: how to check your machines and what to rotate

LiteLLM is the library a lot of us use to call many model APIs through a single interface, or to run a proxy in front of them. On Oct 21, 2026, a malicious version, 1.107.0, went out through its normal channels for a few hours. If you installed or pulled LiteLLM that morning, read this before you do anything else.

Everything below comes from LiteLLM's incident post, last updated Oct 21 at 4:30 PM ET. Times are converted to Eastern.

What shipped, and when

The bad Docker Hub image digest starts with sha256:1bbcb1443bc9. On GHCR, the litellm-database image starts with c00f9d92c427 and litellm-non_root with 7b00e91cd2fe. The full digests are in the incident post.

LiteLLM says the package contained compiled malware that steals credentials and loads remote-code-execution tools. The Enterprise private registry wasn't affected.

How it happened

According to LiteLLM:

• The attacker had three developers' GitHub CLI tokens, one of them from an org owner. They used them to turn off branch protection and force-push.
• The packages were built from a lookalike repo, Berri-AI/litellm. The real source tag on GitHub is clean.
• Release permissions had been expanded temporarily on the Monday before.
• The tokens were probably taken from the logs of an internal LiteLLM deployment that was exposed to the internet. In some cases, Claude Code had embedded GitHub CLI OAuth tokens in response bodies, and those bodies were logged.

How the attacker got into that deployment is still being investigated. LiteLLM says it suspects a recently patched vulnerability and hasn't confirmed it. It also mentions an embargoed fix with a disclosure date of Oct 27.

The lesson for the rest of us is the token-in-logs part. If you log full LLM responses, those logs can hold secrets your agent printed.

Check your machines

On each machine, container image and CI runner that might have installed LiteLLM on Oct 21:

1. Run pip show litellm and look at the version.
2. In site-packages, look for a litellm-1.107.0.dist-info folder, a cook.pth file and an unexpected sitecustomize.py.
3. Check your image digests against the ones above.

A clean result doesn't prove you're clean. LiteLLM says this plainly. If 1.107.0 ran anywhere with outbound internet, treat it as compromised.

We put these checks into a script that's tested against a fake infected environment. It's in the Python and npm supply-chain lockdown kit.

Clean up (in this order)

LiteLLM's steps, in order:

1. Don't run pip first. The malware loads on Python startup, and pip is a Python program.
2. Delete cook.pth, cook.py, sitecustomize.py and their __pycache__ files.
3. Stop the background process holding /tmp/remote_code_loader.lock.
4. Reinstall litellm==1.106.2. It's better to rebuild the environment or image from scratch.
5. Assume your secrets leaked if the host had outbound internet.

What to rotate

LiteLLM's list:

• the cloud IAM role or keys the host could use
• every provider API key stored in the proxy database
• the LiteLLM master key and all virtual keys
• the password in DATABASE_URL
• any other secrets in the environment

On AWS, LiteLLM suggests checking CloudTrail for unexpected GetCallerIdentity calls, which is a quick way to see whose keys you're holding, so it often shows up when stolen keys get tested.

Stop the next one

LiteLLM says this isn't its first incident: there was an earlier one in March. The habits below won't stop a compromised maintainer, but they shrink the window:

• Pin exact versions and commit your lock file.
• Use hashes. pip supports hash-checking mode, so a swapped file fails the install.
• Pin Docker images by digest, not by latest.
• Wait a day before taking new releases of anything that holds your keys.
• Keep secrets out of agent output and logs. See Run coding agents safely and the vibe coding security checklist.

The lockdown kit also includes a Claude Code hook that blocks unpinned pip install and npm install commands before your agent runs them.