LiteLLM, the widely deployed LLM gateway and proxy, was hit by a second supply-chain compromise in 2026. On October 21, a malicious 1.107.0 release was published to PyPI and container images carrying the same payload were pushed to Docker Hub and GHCR. The first incident, in March, involved 1.82.7 and 1.82.8 and is covered in our TeamPCP cascade write-up. This one has no CVE and has not been publicly tied to TeamPCP or any other named actor.

What happened

According to multiple vendor analyses (Socket, StepSecurity, SafeDep, Mend, OX Security, Chainguard), the poisoned PyPI wheels were live from about 11:39 UTC to 13:23 UTC on October 21, when PyPI removed the release. The affected container tags (v1.107.0, latest, main-latest, main-stable) stayed live somewhat longer. Reports disagree on when they were pulled: roughly 13:53 UTC in one account, 14:20 UTC in another. Treat any pull of those tags that day as suspect.

The upstream v1.107.0 git tag reportedly does not contain the malicious files, which points to compromise of the publishing path rather than the reviewed source. Secondary reporting attributing initial access to stolen GitHub CLI credentials of three LiteLLM developers comes from the vendor’s own incident report as relayed by researchers. We could not independently verify it, so treat it as unconfirmed.

Technical details

All seven wheels add three files to site-packages:

  • cook.pth and cook.py: the credential stealer. A .pth file containing an import line is executed by the interpreter at every Python startup, so the stealer runs without anything importing litellm.
  • sitecustomize.py: a backdoor that starts a background loader which fetches and executes remote Python code on an hourly cadence.

The stealer collects SSH keys, cloud provider credentials, CI/CD secrets, AI tool tokens, browser-stored passwords, and the LLM provider API keys held in a LiteLLM proxy’s database. Data is encrypted and sent to www.litellm[.]dev, a lookalike of the project’s legitimate domain. Block it at DNS and egress.

Two properties make this worse than a typical install-time stealer:

  1. Startup hooks fire on every interpreter launch, including unrelated Python processes in the same environment such as build scripts, cron jobs and other services sharing the venv or image.
  2. The hourly loader gives the attacker persistent code execution. Removing the package files does not remove anything the loader has already fetched, so a host that ran the wheel is a rebuild candidate, not a cleanup candidate.

An AI gateway is a particularly rich target: it concentrates provider keys for OpenAI, Anthropic, Bedrock, Vertex and others, often alongside cloud IAM credentials and a database connection string. Researchers reported stolen AWS credentials being validated later the same day.

Impact

Affected: any environment that installed litellm==1.107.0 from PyPI, or pulled/ran the listed Docker tags (including unpinned latest deployments and CI jobs that resolve the newest version) during the exposure window. Last known good: 1.106.2; LiteLLM states earlier versions are unaffected (one vendor names 1.106.0 as safe, so pin to a version you have verified from the official advisory).

PyPI removal and tag cleanup do not undo anything. Stolen secrets remain valid until rotated.

Mitigation

  1. Identify exposure. Search lockfiles, image manifests, build logs and registry pull logs for litellm 1.107.0 and the affected tags between ~11:30 and 14:30 UTC on October 21. Check for cook.pth, cook.py and an unexpected sitecustomize.py in every site-packages.
  2. Isolate and rebuild. Treat any host or container that ran the payload as fully compromised. Rebuild from clean images; don’t just delete the files.
  3. Rotate everything reachable. SSH keys, cloud credentials and instance-role sessions, CI/CD and GitHub tokens, Kubernetes service account tokens, database credentials, and every LLM provider key stored in or reachable from the proxy. Review provider usage logs and cloud audit trails for activity after the exposure.
  4. Block the exfil domain www.litellm[.]dev and hunt for outbound connections to it, plus hourly beaconing from Python processes.
  5. Pin and verify. Pin to a known-good release with hashes (pip install --require-hashes), pin container images by digest rather than tag, and avoid latest in production. A minimum-release-age policy on new package versions would have kept this release out of most builds.

Sources