LiteLLM 1.107.0 was a poisoned build: a credential stealer ran on every Python start, on PyPI and in Docker images

What happened

Early: primary issue read, vendor analyses not openedActive credential theft21 Oct

On 21 October a user reported on the LiteLLM repository that version 1.107.0 was compromised, that PyPI had removed it and that the Docker latest and main-stable tags had been removed (issue 47826). The issue title names a cook.pth credential stealer, a sitecustomize loader that gives remote code execution, and a build from a lookalike repository (Berri-AI/litellm, not BerriAI/litellm). Search results for security vendors’ write-ups (Socket, Wiz, Datadog, JFrog, Chainguard, Endor Labs, StepSecurity) and for LiteLLM’s own incident note describe the same incident consistently. I could not open any of those pages from this environment, so the details below come from their search extracts and are marked as relayed.

As relayed: all seven PyPI wheels for 1.107.0 and the matching Docker images carried three extra files. The package was live from about 11:39 UTC to 13:23 UTC; GHCR tags were unavailable by about 13:51 UTC and Docker Hub tags removed or repointed by about 14:20 UTC. The source at the Git tag is clean. LiteLLM says its release pipeline was compromised, and one report attributes it to stolen developer credentials; the exact entry point is not confirmed, and JFrog is reported to caution that its evidence does not prove which system or credential was used. One vendor reports that stolen AWS credentials were already being used by 22 October. That comes from a single secondary source.

Analysis

Entry point and trust boundary. The boundary crossed is between source and artifact. Code review, tag signing and a clean diff all apply to the repository; consumers install wheels and images. The payload was added after the source step, so the usual “read the diff” control sees nothing. Practically, pip install litellm==1.107.0 and a pull of the official image name returned attacker-built content.

Why Python’s startup hooks make it severe. A .pth file and a sitecustomize module are processed by the interpreter at start-up. The malware therefore runs for any Python process in that environment, including tools that never import LiteLLM, and it re-runs if you try to clean up with Python-based tooling. This is the same persistence trick used in the March 2026 LiteLLM compromise (versions 1.82.7 and 1.82.8, reportedly through a CI dependency), now with different file names, container images in scope and a lookalike build source. A second compromise of the same project in seven months suggests the release process, not one stolen token, is the weak point.

Why an AI gateway is a high-value target. A LiteLLM host typically holds every upstream model-provider key, the gateway’s master and virtual keys, a database URL, and often cloud credentials for Bedrock, Vertex or Azure. One gateway compromise is therefore a bill, a data-access and a lateral-movement problem at once. The reported targeting of AI coding-tool credentials on developer machines (Claude Code, Codex, Gemini and Cursor configuration) extends the blast radius to the people who build agents.

Preconditions and blast radius. Anyone who installed or pulled 1.107.0 in the two-hour PyPI window, or pulled the affected image tags in the longer container window, including CI runners and automated base-image rebuilds. Mapping: OWASP LLM03 (supply chain) and the Agentic Top 10 supply-chain category; MITRE ATLAS ML supply chain compromise. Compare the tensorlake npm release covered on 19 Oct, which also shipped a stealer aimed at AI-tool credentials.

An open detail. A second issue notes that the v1.107.0 Git tag points to a commit whose pyproject.toml declares 1.108.0, and that the tag contains none of the payload files (issue 47842). That is separate from the artifact compromise, but it shows that consumers could not tell from the repository which commit the release was meant to be.

Mitigation and detection

• Contain first. Isolate hosts and pods that ran 1.107.0. Delete the three dropped files from site-packages before running pip, then rebuild from scratch; do not clean in place.
• Rotate. All provider keys, cloud credentials, tokens and database passwords reachable from the host. Revoke before you investigate.
• Hunt. Look in package-proxy logs, lockfile history, image registries and CI logs for 1.107.0 and for pulls of the gateway image on 21 Oct. In network logs, look for outbound requests from Python processes to a domain that imitates the project’s name, and for hourly callbacks. In cloud audit logs, look for new use of keys from unfamiliar addresses since 21 Oct.
• Harden. Pin by hash, install from an internal mirror with a cooldown period for new releases (a delay of even one day would have avoided a window this short), prefer image digests over tags, and run gateways with the minimum credentials they need, preferably short-lived and per-model.

Recommendation (opinion): treat this as a credential incident, not a package update. Because the stealer ran at interpreter start, “we upgraded after two hours” does not mean “we are fine”; the only safe assumption is that whatever the host could read has left it. Put a new-release cooldown on your package proxy this week; it is the cheapest control that would have stopped this one.

Sources: BerriAI/litellm issue 47826: 1.107.0 compromised (title and metadata read; body did not render) · issue 47842: v1.107.0 tag declares 1.108.0 · LiteLLM releases (v1.106.2 listed as latest on 21 Oct) · Vendor and LiteLLM write-ups seen as search results but not opened: LiteLLM incident note, Socket, Wiz, Chainguard, JFrog, Help Net Security

Related reports

• Security brief, 23 Oct
• Security brief, 19 Oct: the tensorlake npm release