Guide · Keys

LiteLLM 1.107.0 was compromised: what to do about your OpenAI, Anthropic and OpenRouter keys

LiteLLM says release 1.107.0 shipped compiled malware that steals credentials. If that package or a compromised Docker tag ran on October 21, clean the environment before you start Python again, then rotate the keys.

Rotated your keys? Start free with one key, no card. BillCurfew emails you when a key passes a daily cap or spikes, checked about every five minutes, with a manual kill on every plan. It's not a proxy, so it doesn't sit in LiteLLM's path.

Last checked . Times below are from the sources. October 21 was still on daylight time, so MDT is six hours behind UTC.

What happened

LiteLLM says that in the early morning of October 21 its release pipeline pushed v1.107.0 to PyPI and the Docker registry, and that this version contained compiled malware which steals credentials. The impacted releases were pulled. LiteLLM also says the official v1.107.0 source tag on GitHub does not contain the malicious files, and that the compromised artifacts were built from an attacker-controlled repository. [1]

JFrog, Datadog, and Microsoft describe the same release: wheels that add cook.pth, cook.py, and sitecustomize.py, which Python runs at startup. cook.pth contains import cook, so cook.py runs even when the application never imports litellm. [2] [3] [4] JFrog says all seven platform wheels for 1.107.0 contain those files, and that the source tarball does not. [3]

LiteLLM later wrote that parts of its own October 21 status post were incomplete. This page sticks to the artifact windows, file names, and cleanup steps the sources still agree on. [1]

Am I affected?

LiteLLM's window for PyPI litellm==1.107.0 is 11:39 UTC to 13:23 UTC on October 21 (5:39 a.m. to 7:23 a.m. MDT). The seven wheels were uploaded from 11:39:51 to 11:40:13 UTC, and PyPI had removed the release by 13:23 UTC. [1]

On Docker Hub, tags v1.107.0, latest, main-latest, and main-stable pointed at compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e from 11:46:56 UTC to 14:20 UTC (5:46 a.m. to 8:20 a.m. MDT). [1] The same four tags on GHCR pointed at compromised indexes from 11:46:56 UTC until they were unavailable by 13:51 UTC (7:51 a.m. MDT). [1] Datadog's timeline is shorter: PyPI quarantine at 13:20 UTC and Docker images removed at 13:53 UTC. [4] Use LiteLLM's window when you decide whether a pull counted, and treat Datadog's clock as a second report, not the same minute.

LiteLLM says you are affected if either of these is true. [1]

  • You used an unpinned LiteLLM install between 11:39 and 13:23 UTC via pip, or you ran pip install of v1.107.0. pip show litellm is how LiteLLM says to check an environment that already started Python. Do that only after the cleanup below, or from a listing that does not start the affected interpreter. [1] [2]
  • You used Docker tags v1.107.0, latest, main-latest, or main-stable between 11:46 and 14:20 UTC, or a container ran image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. [1]

Microsoft says to look for 1.107.0 in installed environments, uv and pip caches, internal package mirrors, lock files, build outputs, and container images, including mutable tags. [2] A mirror or cache that stored the wheel can install it later. Pulling an image does not itself run the payload. The GitHub issue notes that docker pull only unpacks layers. cook.pth and sitecustomize.py run when a Python interpreter starts with that site-packages on its path, including docker run, a RUN step in a derived image, docker exec, or a manual python. [5]

Search for litellm-1.107.0.dist-info, cook.pth, and sitecustomize.py. Finding one confirms exposure. Not finding one does not prove the environment is clean. [1] Pin to litellm==1.106.2, which LiteLLM, Datadog, and JFrog name as the safe pin, or to any explicit version LiteLLM says was published before this release. Pin only after the startup files are gone, or from a newly built environment. [1] [3] [4]

Don't run pip first: clean up without starting Python

LiteLLM's cleanup, credited to the GitHub issue, starts with this rule: don't start with pip install. Any Python start in the affected environment runs cook.pth and sitecustomize.py again, and that includes running pip. [1] [5] Microsoft says the same: do not run python, pip, or anything else that invokes the affected interpreter while you collect evidence. Inspect from a known-clean system. [2] Deleting only the litellm package directory leaves the startup files in place. [2] [4]

  1. From the shell, delete cook.pth, cook.py, sitecustomize.py, and any matching __pycache__/cook*.pyc and sitecustomize*.pyc from every affected site-packages. [1] [5]
  2. Kill the detached Python process that holds /tmp/remote_code_loader.lock. [1] [3]
  3. Reinstall pinned to litellm==1.106.2. Rebuilding images and virtualenvs from scratch is better. [1] [3]

If 1.107.0 was ever installed on a host with outbound internet, LiteLLM says to assume the exfiltration succeeded. A marker file confirms it. If the marker is missing, that proves nothing: containers and temporary-directory cleanup remove it. [1] JFrog names the run-once marker /tmp/.pc_once_72129118c59f5636c0bb and says it is written only after a successful upload. [3]

On Windows, JFrog says the sitecustomize.py daemon cannot finish because it calls os.fork(). cook.pth still imports cook.py, so the credential stealer still runs. [3]

Rotate every key the proxy held

Do this from a clean machine. LiteLLM says to rotate everything the host could reach, and in particular: [1]

  • Every provider key stored in the LiteLLM proxy database. That includes OpenAI, Anthropic, and OpenRouter keys if the proxy was configured with them, and any other provider key in that database. JFrog says the payload reads LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable through DATABASE_URL. [1] [3]
  • The LiteLLM master key and virtual keys. [1] [3]
  • The DATABASE_URL password. [1] [2]
  • The instance or task IAM role, and any secret that was in the environment of any process on the host. On Linux the collector also reads other processes' environments. [1] [2] [3]

Revoke the provider key at the provider. Deleting it from the proxy, or from the environment, does not stop a copy. The provider steps are in the leaked-key guide. If the key was committed to a public Git repo, deleting that commit does not revoke it either. A scan of public Gitee repositories is the Gitee guide.

Check for spend you didn't make

Review per-key usage at OpenAI, Anthropic, and OpenRouter from October 21, 2026 onward, for each key the proxy held. Keep the export. LiteLLM also says to check CloudTrail for GetCallerIdentity from the instance role around install time, then for use of that role's credentials from outside your infrastructure. [1] This page does not prescribe a provider console click-path.

Ask the provider about unauthorized charges

If the usage is not yours, write to that provider with the key name or last characters, the time you revoked it, and the usage export. Do not send the secret. The leaked-key guide is the longer checklist for OpenAI, Anthropic, and OpenRouter. These LiteLLM sources do not promise a refund.

Put a ceiling on the new keys

After the new keys are in place, give each tool its own key and a daily cap where the provider allows one. The daily budget guide covers OpenAI, Anthropic, and OpenRouter. A proxy budget only sees traffic that passes through the proxy. How that compares with a provider limit and with BillCurfew is on the spend limits vs proxies page.

BillCurfew watches per-key spend at the provider. It emails on a daily cap or a spike. The check is about every five minutes. A manual kill works on every plan, including Free. Auto-kill is on paid plans only and stays off until you turn it on. None of that detects this malware, blocks the next request, or revokes a stolen key the moment it is copied.

FAQ

Was every LiteLLM version affected?

No. LiteLLM says all previous versions are safe. The compromised PyPI release was litellm==1.107.0, all seven wheels, and the compromised Docker tags were v1.107.0, latest, main-latest, and main-stable during the windows below. The official v1.107.0 Git source tag does not contain the malicious files, and the source tarball does not contain cook.pth, cook.py, or sitecustomize.py. Those files were in the wheels. Installing the Git tag does not remove them from an environment that already ran the wheel. [1] [3]

Is importing LiteLLM once enough to run the payload?

You do not have to import it. cook.pth runs import cook when Python starts, and Python also imports sitecustomize. Any Python start in that environment, including pip, can run the payload even if the application never imports litellm. [2] [3] [4]

Was LiteLLM Enterprise affected?

LiteLLM says enterprise customers running the private enterprise release, and pulling from its private registry, were not impacted. That statement is about that private registry, not about every company that uses LiteLLM. [1]

Which keys should I rotate first?

The metered provider keys. LiteLLM says to rotate every provider key stored in the proxy database, plus the master and virtual keys and the DATABASE_URL password. OpenAI, Anthropic, and OpenRouter keys in that database can keep billing while you rotate the rest, so cut those off first. [1] [3]

Can BillCurfew stop a stolen key?

It cannot stop the next request, and it does not detect malware. It emails you when a watched key crosses a daily cap or a spike, on the next check, about every five minutes. A manual kill works on every plan, including Free. Auto-kill is paid-only, stays off until you turn it on, and does not block the next request.

Sources

  1. LiteLLM, Contained: Oct 21, 2026 release v1.107.0 compromised. https://docs.litellm.ai/blog/security-incident-oct-21-2026
  2. Microsoft Security Blog, Inside the LiteLLM 1.107.0 supply chain compromise. https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/
  3. JFrog Security Research, LiteLLM hijacked again. https://research.jfrog.com/post/litellm-hijacked-again/
  4. Datadog Security Labs, LiteLLM supply chain compromise. https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/
  5. GitHub, BerriAI/litellm issue 47826. https://github.com/BerriAI/litellm/issues/47826