LiteLLM release pipeline hacked to distribute info-stealer malware

Summary

BleepingComputer reports that attackers compromised LiteLLM's release pipeline on October 21, 2026, and distributed malicious version 1.107.0 through PyPI, Docker Hub, and GitHub Container Registry. All seven PyPI wheels were affected, exposing Windows, Linux, and macOS environments. Container exposure also included mutable tags such as latest, main-latest, and main-stable, not just the version-specific tag.^[0]

The reported modification was in the installation package rather than LiteLLM application code. Three files—cook.pth, cook.py, and sitecustomize.py—were placed in the environment's Python library directory and used Python startup behavior to execute before the application. This made ordinary investigation hazardous: launching Python or pip in an affected environment could trigger the payload.^[0]

The payload targeted credentials and sensitive data well beyond AI-provider keys, including cloud and deployment secrets, developer tokens, private keys, browser databases, and environment variables. It encrypted collected data before uploading it to litellm.dev. A detached loader launched through sitecustomize.py also checked a GitHub-hosted pointer hourly to obtain further executable content.^[0]

The report says the malicious artifacts were removed and identifies LiteLLM 1.106.2 as the recommended clean recovery version at publication. Recovery requires more than uninstalling the package: the stated response is to stop affected deployments, inspect without starting Python, isolate and rebuild infected systems, and rotate exposed secrets. The maintainer said private enterprise customers were unaffected. These findings are single-source: the supplied incident account quotes maintainers and researchers, but their underlying reports were not supplied as independent evidence.^[0]

Attack chain

1. 1. Release-pipeline compromise and malicious publication: On October 21, attackers used the compromised LiteLLM release pipeline to publish malicious version 1.107.0 to PyPI and container registries. The supplied account does not explain how the attackers initially gained control of the pipeline.^[0]
2. 2. Installation-package implantation: The altered installation package placed cook.pth, cook.py, and sitecustomize.py in the environment's Python library directory. Researchers quoted in the report said the LiteLLM application code itself was not modified.^[0]
3. 3. Python-startup execution and detached loading: During normal startup, Python processed executable .pth lines and attempted to import sitecustomize, causing malicious execution before the application. The malicious sitecustomize.py launched a detached loader that checked a GitHub-hosted pointer every hour and downloaded Python from an external server for execution. Launching Python or pip for investigation could also activate the malware.^[0]
4. 4. Sensitive-data collection: The collector targeted cloud and infrastructure credentials; AI-development authentication files and LiteLLM provider settings; Git, GitHub, npm, PyPI, and CI/CD secrets; .env files; SSH, GPG, and TLS keys; browser login, cookie, payment, autofill, and history databases; environment variables; shell and application histories; and system and network information.^[0]
5. 5. Encrypted exfiltration: The collected data was encrypted using AES-256-CBC. The AES key was encrypted using RSA-4096, and the resulting data was uploaded to the healthcheck endpoint on litellm.dev.^[0]

Disclosure timeline

How it works

The technical mechanism described is malicious packaging and Python startup execution, rather than exploitation of a specified software vulnerability. Researchers quoted in the report said the attacker left LiteLLM application code unchanged and modified the installation package to install three malicious files in the Python library directory.^[0]

Python processes executable lines in .pth files and then attempts to import sitecustomize during normal startup. The implanted cook.pth and sitecustomize.py therefore provided execution opportunities before the application ran. The report warns that using Python or pip to inspect an affected installation could itself trigger execution.^[0]

The malicious sitecustomize.py launched a detached loader, creating a follow-on execution capability beyond the initial collection payload. The loader checked a GitHub-hosted pointer hourly and downloaded Python from an external server for execution. The supplied account does not provide the pointer location or external-server address.^[0]

The collection and exfiltration mechanism combined broad credential and host-data harvesting with encrypted upload. Data was encrypted using AES-256-CBC, with the AES key protected using RSA-4096, before transmission to the healthcheck endpoint on litellm.dev.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• Application-code review alone would not capture the reported modification: the attacker altered the installation package and used Python startup hooks to execute before LiteLLM ran.^[0]
• Investigation can activate this payload. Avoid starting Python or pip inside a suspect environment while inspecting the installed artifacts.^[0]
• Exposure assessment must include mutable container tags and multiple registries, not just an explicit dependency on litellm 1.107.0.^[0]
• Artifact removal does not resolve host compromise or credential exposure. The reported detached loader and broad collection scope support rebuilding infected environments and rotating exposed secrets.^[0]
• Do not transfer attribution from the earlier March incident to this event. The supplied report names TeamPCP only in connection with the previous compromise and does not name an actor for the October attack.^[0]

Defensive actions

• Stop affected deployments and isolate systems that ran the compromised artifacts.: The report explicitly recommends stopping potentially affected deployments and isolating infected systems. The payload combines broad credential theft with a detached follow-on loader.^[0]
• Inspect affected environments without launching Python or pip, including inspection of the Python library directory for the reported startup files.: Python startup processing can execute the implanted payload before the application. The article specifically warns that Python or pip used during investigation can trigger the malware.^[0]
• Scope exposure using package versions, container image identities, and the registry-specific publication windows, rather than relying only on current tag names.: All seven 1.107.0 wheels were affected, while both versioned and mutable container tags pointed to compromised indexes during bounded windows. The complete Docker Hub image-index digest provides a concrete matching value.^[0]
• Rebuild infected environments from clean backups instead of treating LiteLLM package-directory deletion as complete remediation.: The report warns that removing the package directory alone may leave Python startup files or an active loader behind and recommends rebuilding infected systems.^[0]
• Rotate all exposed secrets, covering cloud and infrastructure credentials, AI-provider and development-tool authentication, repository and package-registry tokens, CI/CD secrets, and private keys.: These categories were within the reported collection scope. The source explicitly recommends immediate rotation of exposed secrets rather than limiting response to LiteLLM credentials.^[0]
• Hunt for and block outbound communication to litellm.dev.: The domain was the reported destination for encrypted stolen data. Communication with it is a concrete incident-specific investigation and containment lead.^[0]
• Use the reported clean recovery release, LiteLLM 1.106.2, when restoring service after containment and environment recovery.: The article identifies 1.106.2 as the latest clean release before the attack and the recommended recovery version at publication. A version change alone does not address residual startup files, a detached loader, or already exposed credentials.^[0]