system: OPERATIONAL
← back to all hacks
SUPPLY CHAIN CRITICAL NEW

LiteLLM 1.107.0: a poisoned release that steals credentials at Python startup

On 21 October 2026 a backdoored LiteLLM 1.107.0 reached PyPI and container registries. Its .pth startup hook ran on every Python launch to harvest cloud and AI-provider credentials.

2026-10-27 // 6 min affects: litellm, litellm-proxy, python-environments, container-images

What is this?

On 21 October 2026, a malicious build of LiteLLM 1.107.0 was published to PyPI and shipped in official container images. Microsoft Security Research documented the incident on 23 October 2026, and LiteLLM published a root cause analysis the same day, according to a third-party timeline. Microsoft lists no CVE for it; it tracks the issue internally as TVM-2026-0003. Only version 1.107.0 is reported as affected, and 1.106.2 is named as the last safe release. The package was pulled from PyPI the same day, and the affected container tags were removed or repointed to clean artifacts.

How it works

The wheels installed three extra files into site-packages: a .pth file, a Python module it imports, and a sitecustomize.py. Python executes .pth lines containing import during interpreter start-up, so the payload ran whenever Python launched in that environment, even if the application never imported LiteLLM. This matches the MITRE ATT&CK technique “Python startup hooks” (T1546.018).

According to Microsoft, the payload was a credential collector. It targeted developer and AI-tool configuration, cloud credentials, browser data, SSH keys, process environment variables and the tables of the LiteLLM proxy database. Data was encrypted and sent to an attacker-controlled domain. A second path on Unix systems read a pointer from a GitHub-hosted file and could fetch further code; at the time of analysis that pointer was empty and no second stage was confirmed.

The build itself was subverted rather than the source. LiteLLM states that stolen GitHub credentials of several engineers let the attacker redirect the release workflow to a lookalike repository and satisfy the production approval step. A third-party timeline says the starting point was an unrevoked key committed to a public repository in May 2026. Microsoft notes it has not independently confirmed how the developer credentials were obtained, and some timings differ between sources.

Example prompt

Illustrative and redacted: this shows the shape of the weakness, not a usable payload.

# Startup-hook triage for a suspect Python environment (illustrative, defensive, redacted)
# Pattern: a .pth line starting with 'import' runs at every interpreter launch.
#   [startup files]  -> .pth + helper module + sitecustomize.py in site-packages   [REDACTED]
#   [collector]      -> harvests env vars, cloud and AI-provider keys               [REDACTED]
#   [exfil domain]   -> encrypted upload to attacker-controlled host                [REDACTED]
# Defense: inspect from a clean system (never run Python in the suspect one), pin images
# by digest, rebuild from verified artifacts, rotate every secret the host could read.

Why it matters

An LLM gateway sits on provider API keys, cloud roles and databases by design, so one compromised release concentrates many secrets. The startup-hook mechanism also defeats the usual cleanup: deleting the litellm folder leaves the hook files behind. LiteLLM advises assuming compromise if 1.107.0 ran in an environment or a container used the affected image digest. No install count is published.

Defenses

  • Search lockfiles, caches, internal mirrors, build logs and running containers for 1.107.0. Pin images by digest, not mutable tags.
  • Do not run pip or Python in a suspect environment to investigate, because start-up re-executes the hooks. Inspect from a clean system.
  • Rebuild from verified artifacts and confirm the three startup files are absent from site-packages.
  • Rotate everything the host could read: provider keys, master and virtual keys, cloud and CI secrets, SSH keys, database URLs. Revoke active sessions.
  • Review network and cloud audit logs for traffic to the exfiltration domain and for unexpected use of instance-role credentials.
  • Use hash-pinned lockfiles, verified provenance, restricted egress, and narrowly scoped release tokens with enforced multi-person approval.

Status

ItemDetail
AffectedLiteLLM 1.107.0 (PyPI wheels, container tags)
Last safe version1.106.2
Malicious release published2026-10-21
Microsoft analysis2026-10-23
IdentifierNo CVE; Microsoft TVM-2026-0003

Sources