LiteLLM 1.107.0 was backdoored on PyPI and Docker: startup hooks stole credentials even without an import

On October 21, 2026, LiteLLM's release process distributed malicious version 1.107.0 to PyPI (11:39–13:23 UTC) and affected Docker Hub/GHCR image tags (approximately 11:46–14:20 UTC). All seven wheels carried cook.pth, cook.py and sitecustomize.py, which execute during Python interpreter startup to steal credentials and install a remote-code loader. The maintainer says affected artifacts were removed or repointed and the private enterprise registry was not impacted. JFrog independently compared wheels, source tarball and Git tag and found the payload absent from the public source tag. The investigation into how attackers passed multiple release controls remains ongoing.

LiteLLM proxies often sit beside cloud roles, database URLs and multiple AI-provider keys. Installing the compromised package or running an affected container can expose credentials beyond the LiteLLM application, including secrets accessible to the host or CI runner. A clean-looking source tag does not prove a built wheel is safe, and simply reinstalling a safe version cannot revoke secrets already copied. Builders should inspect actual resolved dependencies and image digests, isolate affected hosts, rebuild environments and rotate accessible credentials.

LiteLLM identifies litellm==1.107.0 PyPI wheels as exposed between 11:39 and 13:23 UTC on October 21. The affected Docker Hub and GHCR variants included v1.107.0, latest, main-latest and main-stable while they resolved to compromised image indexes. The main Docker index digest was sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. A floating tag pulled after cleanup is not evidence of what ran earlier; check deploy records and image digests.

JFrog found cook.pth, cook.py and sitecustomize.py in the seven published wheels, but not in the GitHub v1.107.0 tag. A build-time Maturin data = cook setting included additional files from the wheel build tree. Python processes can execute .pth import lines and sitecustomize.py during interpreter startup even if LiteLLM itself is never imported. JFrog says this narrows the injection mechanism but does not independently prove exactly how the release pipeline was compromised.

The startup hook ran a credential collector that searched for cloud credentials, environment variables and service secrets; another component started a detached loader capable of remote code execution. JFrog observed the loader's dead-drop configuration empty at one point, but that observation did not neutralize the credential stealer or prove the loader could not later be activated. On Windows the loader's fork-based daemon fails, but the credential stealer still runs.

The maintainer advises treating any affected environment as compromised. Avoid launching Python or pip within the infected environment before removing startup hooks, because startup can retrigger them. Isolate the host, investigate execution and outbound access, rebuild clean environments, and pin a known-safe release such as 1.106.2. Rotate all reachable provider, database, cloud IAM, registry and service credentials, including secrets stored in the LiteLLM proxy database. Absence of cook files or marker files does not prove no execution or exfiltration.

JFrog documented an earlier LiteLLM compromise in March 2026 involving different versions and a malicious Trivy dependency in the build process. It finds no current evidence tying the October 1.107.0 campaign to that earlier access path. LiteLLM says three developer GitHub credentials were compromised and has restricted organisation access and revoked publishing trust while investigating.

The full entry point, number of affected users, extent of credential exfiltration, and any subsequent misuse remain unconfirmed. Maintainer timestamps are incident findings that may change with later forensic updates. The official private enterprise registry is stated to be unaffected; that is not a blanket guarantee for independently operated environments.