“92 million monthly downloads on PyPI” — a figure that underscores both LiteLLM’s reach and the scale of risk after an attacker pushed a malicious release into the project’s distribution pipeline on October 21, 2026.
How the release pipeline was compromised on October 21
The LiteLLM maintainer says the project’s release pipeline was compromised on October 21 and a threat actor pushed LiteLLM version 1.107.0 to both the Docker registry and PyPI. “This version contained compiled malware which steals credentials and loads remote-code execution tools,” the maintainer said, adding that customers running the private enterprise were not impacted.
Multiple application-security firms detected the malicious release within six minutes of publishing and proceeded to analyze the payload. Researchers report the attacker did not change the LiteLLM application code; instead, the installation package itself was modified to ensure the malware executed whenever Python started in an affected environment.
Which artifacts and platforms were affected — exact files and timestamps
- PyPI: litellm==1.107.0 — all seven wheels were live from 11:39:51 to 13:23 UTC.
- Docker Hub: tags v1.107.0, latest, main-latest, and main-stable pointed to a compromised image index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e from 11:46:56 to 14:20 UTC.
- GitHub Container Registry (GHCR): tags v1.107.0, latest, main-latest, and main-stable were pointed to compromised image indexes starting at 11:46:56 UTC until they were made unavailable by 13:51 UTC. Examples include:
- ghcr.io/berriai/litellm: sha256:1bbcb1443bc9…
- ghcr.io/berriai/litellm-database: sha256:c00f9d92c427…
- ghcr.io/berriai/litellm-non_root: sha256:7b00e91cd2fe…
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildMalicious payload, execution method, and what was stolen
Researchers found three malicious files inserted into the Python library directory during installation: cook.pth, cook.py, and sitecustomize.py. Socket researchers explained that “during normal startup, Python processes executable .pth lines and then attempts to import sitecustomize,” a sequence that allowed the payloads to run before the application. Endor Labs emphasized this means the payload executes every time Python is launched in an affected environment and that running Python or pip to investigate an installation also triggered the malware.
The payload targeted a broad set of secrets and data, including:
- Cloud and deployment credentials: AWS, Azure, Google Cloud, Kubernetes, Docker, and infrastructure-management secrets.
- AI credentials and configuration: authentication files for AI development tools plus LiteLLM’s stored provider credentials and model settings.
- Developer secrets and private keys: Git, GitHub, npm, PyPI, CI/CD credentials; .env files; SSH, GPG, and TLS keys.
- Browser data: saved logins, cookies, autofill/payment and browsing-history databases.
- Host and runtime data: environment variables, shell and application histories, and system and network information.
Stolen data were encrypted on the host using AES-256-CBC, with that AES key then encrypted under an RSA-4096 key and uploaded to litellm[.]dev/healthcheck. One malicious component, sitecustomize.py, launched a detached loader that checks a GitHub-hosted pointer hourly and downloads Python from an external server for execution on the host.
Immediate remediation and recommended recovery actions
The compromised packages have been removed from the registries, but the project and security researchers issued explicit operational guidance:
- Stop affected deployments and inspect environments without launching the Python interpreter; running Python or pip can trigger the loader.
- Isolate infected systems and rebuild from clean backups.
- Rotate all exposed secrets immediately — credential theft is the primary objective of the payload.
- Removing the LiteLLM package directory alone may leave startup files or an active loader behind, so a full environment inspection is required.
- The recommended recovery version is LiteLLM 1.106.2, the latest clean release before the attack.
What this means for technologists, affected enterprises (NVIDIA, Netflix, AT&T, Okta), and open-source maintainers
- Technologists and security teams: the attack shows how installer-level modifications (.pth and sitecustomize hooks) can subvert systems even without changing application code; detection efforts that flagged the release in six minutes are useful, but teams must inspect runtime startup artifacts and not rely solely on package removal.
- Affected enterprises named as users — NVIDIA, Netflix, AT&T, and Okta — should treat any use of litellm==1.107.0 or images with the listed SHA prefixes as potentially compromised and follow the project’s remediation steps, including secret rotation and rebuilding affected hosts.
- Open-source maintainers: the incident echoes a prior March breach in which the TeamPCP group published malicious LiteLLM versions on PyPI after breaching Aqua Security’s Trivy tooling used in LiteLLM’s CI/CD pipeline, underscoring the continuing need to harden release pipelines and supply-chain tooling.
The malicious release was short-lived in the public registries, but the attack’s mechanics — installer-level persistence, hourly remote pointers, and broad credential harvesting — leave a clear operational footprint and a narrow window for containment. The immediate questions are tactical and specific: have deployments unintentionally launched Python since 11:39:51 UTC on October 21, and have those environments been rebuilt and secrets rotated? The project’s advice is unambiguous: treat impacted environments as compromised and proceed to isolate, rebuild, and rotate.
