Supply Chain Compromise in LiteLLM 1.107.0 Triggers Massive Credential Theft Campaign
A sophisticated supply chain attack targeting the LiteLLM library has exposed a wide array of developer and cloud environments to credential theft. On October 21, 2026, a malicious version of the package, identified as LiteLLM 1.107.0, was published to the Python Package Index (PyPI) and subsequently integrated into official container images. The breach, which utilized compromised developer credentials to manipulate the official release workflow, highlights the significant risks posed by automated dependency management in modern software development pipelines.
The malicious payload was designed for automatic execution, bypassing the need for an application to explicitly import the LiteLLM library. By leveraging Python’s standard initialization processes, the attackers placed malicious startup files, specifically cook.pth, cook.py, and sitecustomize.py, into the Python environment’s library directory. These files were structured to trigger during the interpreter’s normal startup sequence, ensuring the payload would execute even if the user was merely running unrelated Python tasks or administrative commands.
Once active, the malware deployed a multi-stage credential collector. This component was engineered to scan developer workstations, CI/CD agents, and cloud infrastructure for sensitive authentication material. The collector targeted a broad range of assets, including API keys for AI model providers, cloud configuration files for AWS and Google Cloud, Kubernetes service account tokens, SSH keys, and browser-stored credentials. Data was then encrypted using AES-256-CBC, with the encryption keys protected by an RSA public key, before being exfiltrated to an attacker-controlled endpoint.
Beyond immediate credential harvesting, the compromised package included a secondary, Unix-oriented loader. This mechanism was configured to check a remote, attacker-controlled domain for additional Python code to download and execute. While researchers observed this loader waiting for instructions, the potential for re-arming the environment with further malicious modules underscores the severity of this persistent threat. Because these startup files resided outside the standard application directory, traditional package removal methods were insufficient to fully sanitize compromised environments.
Security teams are advised to treat any system that hosted the compromised 1.107.0 release as potentially compromised. Mitigation efforts should prioritize the rotation of all credentials accessible to the affected identity—including CI/CD secrets, cloud workload identities, and model provider tokens—from a known-clean machine. Simply deleting the LiteLLM directory is inadequate; organizations must manually verify the removal of the malicious startup files and, where possible, rebuild environments from verified, immutable artifacts.
To defend against similar supply chain threats, organizations should move toward using hash-pinned lock files and container image digests rather than mutable tags. Restricting outbound network access for build agents and developer workstations can also prevent the exfiltration of stolen data and the retrieval of second-stage payloads. Security professionals should leverage endpoint detection and response (EDR) tools to monitor for suspicious process ancestry and unauthorized network connections originating from Python interpreters, which remain a primary vector for this campaign.
