LiteLLM 1.107.0 compromise: how to check if you were hit and clean up

LiteLLM says release 1.107.0 of its open-source Python package and Docker images was malicious, after attackers hijacked its release pipeline on October 21. According to LiteLLM, the version "contained compiled malware which steals credentials and loads remote-code execution tools." All earlier versions are safe, and the bad artifacts have been pulled from PyPI, Docker Hub and GHCR.

This guide covers how to tell whether you were exposed, what to remove and what to rotate. All times are UTC on October 21, 2026.

Am I affected?

PyPI: litellm==1.107.0. All seven wheels were live from 11:39:51 to about 13:23 UTC, according to LiteLLM. You are affected if an unpinned install pulled LiteLLM in that window, or if any environment ever started Python with 1.107.0 installed. The source tarball and the official GitHub v1.107.0 tag do not contain the payload files, so checking only source code won't catch it, according to JFrog.

Docker Hub. The tags v1.107.0, latest, main-latest and main-stable pointed to compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e from 11:46:56 to 14:20 UTC.

GHCR. The same four tags pointed to compromised indexes from 11:46:56 UTC until they were made unavailable by 13:51 UTC. LiteLLM lists these digest prefixes:

• ghcr.io/berriai/litellm: sha256:1bbcb1443bc9…
• ghcr.io/berriai/litellm-database: sha256:c00f9d92c427…
• ghcr.io/berriai/litellm-non_root: sha256:7b00e91cd2fe…

Enterprise private registry. LiteLLM says enterprise customers pulling from its private registry were not affected.

How to check

Check the installed version, carefully. LiteLLM suggests pip show litellm. But pip is Python, and on an infected host any Python start re-runs the payload. So check from the shell first:

# Find payload files and 1.107.0 metadata without starting Python
find / \( -name 'litellm-1.107.0.dist-info' -o -name 'cook.pth' -o -name 'cook.py' -o -name 'sitecustomize.py' \) 2>/dev/null
ls -l /tmp/remote_code_loader.lock 2>/dev/null

Two more Python-free checks. The first lists every installed LiteLLM version without pip show. The second looks for the exfiltration marker file and for the loader daemon:

# Show installed LiteLLM versions without starting Python
find / -path '*site-packages*' -name 'litellm-*.dist-info' 2>/dev/null

# Exfiltration marker, then the process holding the loader lock
ls /tmp/.pc_once_72129118c59f5636c0bb 2>/dev/null
fuser -v /tmp/remote_code_loader.lock 2>/dev/null || lsof /tmp/remote_code_loader.lock

Datadog and Wiz name /tmp/.pc_once_72129118c59f5636c0bb as a marker file. LiteLLM says, "If the marker file exists, the exfil is confirmed." If fuser or lsof shows a process holding the lock, that is the daemon to kill.

According to LiteLLM, finding any of litellm-1.107.0.dist-info, cook.pth or sitecustomize.py confirms exposure. Not finding them does not prove the environment is clean.

Check image digests. Any container that ran digest sha256:1bbcb1443bc9… (or the GHCR digests above) should be treated as compromised.

docker images --digests | grep litellm
docker inspect --format '{{json .RepoDigests}}' <image>

A floating tag pulled during the window may still be cached locally. Compare the digest, not the tag.

What to delete

LiteLLM's steps, which it credits to researcher LidorMachluf, start with a warning: don't begin with pip install. Any Python start in the affected environment runs cook.pth and sitecustomize.py again, and that includes pip.

1. From the shell, delete cook.pth, cook.py and sitecustomize.py, plus any __pycache__/cook*.pyc and sitecustomize*.pyc, from every affected site-packages directory.
2. Kill the detached Python daemon that holds /tmp/remote_code_loader.lock.
3. Reinstall pinned to litellm==1.106.2. LiteLLM says rebuilding images and virtualenvs from scratch is better.

For Docker, pin an explicit version instead of latest, main-latest or main-stable. Pinning by digest (image@sha256:…) after you check it is a common hardening step. LiteLLM's post doesn't specifically recommend it.

What to rotate

LiteLLM says that if 1.107.0 was ever installed on a host with outbound internet access, you should assume the exfiltration worked. Rotate everything the host could reach, especially:

• the instance or task IAM role
• every provider key stored in the LiteLLM proxy database, plus the master and virtual keys
• the DATABASE_URL password
• any secret in the environment of any process on the host

Datadog Security Labs recommends doing the rotation from a clean machine. LiteLLM also suggests checking CloudTrail for GetCallerIdentity calls from the instance role around install time, then for use of that role's credentials from outside your infrastructure. The stealer also goes after cloud, developer, browser and AI-tool credentials, according to Datadog and Wiz. Check what else on the host was exposed.

What happened

According to LiteLLM, someone used three sets of stolen developer GitHub CLI credentials. One belonged to a GitHub organization owner. The attacker used it to override branch protection on LiteLLM's private release workflow. A second credential was used to pass the production approval gate at 11:11:18 UTC. The attacker then pointed the workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm. That run signed and published the poisoned artifacts. A third account's credentials were then used to delete the workflow records.

LiteLLM believes the attacker got the GitHub CLI OAuth tokens from the logs of an internal LiteLLM deployment that was exposed to the internet. It says Claude Code can, in some cases, embed a user's GitHub CLI OAuth token in a response body, and that logged response bodies can end up in LiteLLM logs. The company hasn't confirmed how the attacker got into that deployment, but suspects a recently patched vulnerability.

This is the second LiteLLM supply-chain compromise this year, after versions 1.82.7 and 1.82.8, according to Datadog. LiteLLM and OX Security place the earlier incident in March. Datadog says no link between the two has been established. LiteLLM says its investigation is ongoing and promised updates every two hours. Its post was last updated at 20:30 UTC. It promised a status update at 22:30 UTC, but none had been posted as of 23:35 UTC. Community tracking is in GitHub issue #47826.