LiteLLM Release Pipeline Compromise: Exposure Window and Recovery

Thu Oct 22

October 21, 2026: The release pipeline for LiteLLM, the open-source gateway that routes requests to many AI model providers, was compromised. Malicious PyPI wheels for litellm 1.107.0 and matching Docker Hub and GHCR container tags were live for roughly two hours before they were removed. The payload is an information stealer that collects cloud, AI, developer and browser credentials. Canonical: litellm-release-pipeline2026. Primary source: LiteLLM's post-mortem.

LiteLLM sits in an unusual place in the stack. It is installed in build pipelines, notebooks, servers and containers, and it is usually deployed next to the keys for every model provider a company uses. Compromising the package therefore gives an attacker the credentials for the whole environment the package runs in, not just the package itself. The maintainers say the package has around 92 million monthly downloads on PyPI.

Timeline (UTC, October 21)

11:39:51: the malicious 1.107.0 wheels became available on PyPI.
11:46:56: the Docker Hub tags v1.107.0, latest, main-latest and main-stable started pointing at a compromised image index. GHCR tags followed the same timing.
13:23: the PyPI wheels were removed.
13:51: GHCR images were no longer available.
14:20: the Docker Hub tags were fixed.

Several application-security firms flagged the release within six minutes of publication, which is why the exposure window was short.

Technical analysis

How the package was changed

The maintainers say the application source code was not changed. The attacker added three files to the package's installation directory in site-packages: cook.pth, cook.py and sitecustomize.py. A .pth file in site-packages is processed by Python at interpreter startup, and the sitecustomize module is imported automatically. The result is that the payload runs whenever Python starts in that environment, including when you run python or pip to investigate. Importing LiteLLM is not required.

According to Endor Labs and Socket, the loader then checks a GitHub-hosted pointer about once an hour and retrieves further code from an external server. The maintainers' post-mortem describes the compiled malware as stealing credentials and loading remote-code-execution tools.

What it targets

Cloud and deployment: AWS, Azure, Google Cloud, Kubernetes, Docker and infrastructure-management credentials.
AI: provider API keys and LiteLLM's own stored credentials and model configuration.
Developer: Git, GitHub, npm and PyPI tokens, CI/CD secrets, .env files, SSH and GPG keys, and TLS material.
Browser and host: logins, cookies, autofill data, shell and application histories, and environment variables.

Collected data is encrypted with an AES-256-CBC key, which is itself protected with RSA-4096, and uploaded to a domain registered as litellm[.]dev (defanged here). Block that domain at egress and search DNS and proxy logs for it.

Why the blast radius is wider than the package

A gateway like LiteLLM is usually installed where the most credentials already live. Common deployments include a CI runner that holds cloud deploy keys, a container that carries provider API keys as environment variables, a developer laptop with SSH keys and cloud CLI profiles, and a notebook server with access to internal data. Each of those environments can contain credentials that have nothing to do with LiteLLM. An installer that runs in any of them therefore reaches far beyond the package's own configuration.

That is also why a short exposure window still matters. A few hours is enough if a build job or a developer runs an install during that time, because the installed package is what runs later in production, long after the registry has removed the bad version. Check not only where the package runs today, but every image, cache and artifact built during the window.

Scope and what is not affected

Affected: PyPI litellm==1.107.0 (all seven wheels), and the Docker Hub and GHCR tags listed above during their windows.
Not affected: application code in the repository, and the private enterprise build, according to the maintainers.
Unknown: how the release pipeline was accessed. The post-mortem reported so far does not say, and it is too early to know whether the March 2026 TeamPCP campaign is related.

How to tell whether you installed it

Check the installed version in every virtual environment, container and CI cache: pip show litellm or python -c "import importlib.metadata as m; print(m.version('litellm'))". Note that python itself may run the payload, so start with the metadata on disk rather than an interpreter if you suspect a host.
Look for the three files in site-packages: cook.pth, cook.py and sitecustomize.py. Their presence alone is enough to treat the environment as compromised.
Check image digests for the affected Docker and GHCR tags. A digest beginning sha256:1bbcb14 on litellm, c00f9d9 on litellm-database, or 7b00e91 on litellm-non_root is from the compromised index.
Review egress logs from the time the package was installed for connections to GitHub pointer endpoints and to the exfiltration domain.

Recovery

Stop deployments that used 1.107.0, and do not restart them until they are rebuilt.
Rebuild from known-good state. Deleting the package directory is not enough, because the startup hooks and any running loader can survive. Rebuild the host or container from a clean base image.
Pin to LiteLLM 1.106.2, the last clean release before the attack, and verify the hash of the wheel you install.
Rotate every credential the environment could read. That includes cloud keys, AI provider keys, CI tokens, SSH keys and any secret in .env files. Rotate at the provider, not only in your secret store.
Audit cloud activity from the exposure window for logins, new keys, new users or resource changes that you cannot explain.

Lessons for teams that ship packages

The changes in this attack were made outside the source repository, in the artifacts that users install. Reviewing source code does not catch that. Teams that depend on a fast-moving AI library should pin exact versions in lock files, verify hashes in CI, and watch for new .pth files in site-packages as a routine check. The OVHcloud CLI release hijack covers the same lesson for installed artifacts, and the March 2026 LiteLLM PyPI compromise shows the wider pattern.

Sources

LiteLLM post-mortem • BleepingComputer • Socket • Endor Labs