Malware rode in LiteLLM's installer

On October 21 an attacker pushed LiteLLM 1.107.0 to PyPI and two container registries with compiled malware baked into the installation package. The code steals credentials, secrets, and environment variables, loads remote-code-execution tooling, and runs before the application does. LiteLLM is an open-source Python SDK and AI gateway that fronts models from multiple providers behind one API. It has 61,800 GitHub stars, 92 million monthly PyPI downloads, and names like NVIDIA, Netflix, AT&T, and Okta among its users. The maintainer says customers on the private enterprise build were not affected.

The attacker never touched the application code. They modified only the installer, dropping three files into Python’s library directory: cook.pth, cook.py, and sitecustomize.py. That placement is the whole trick. During startup Python executes the lines in any .pth file it finds, then imports sitecustomize if one exists. Both run automatically, so the payload fires every time Python launches in that environment, ahead of anything LiteLLM does. Endor Labs points out the obvious consequence: running python or pip to poke at an affected install triggers the malware. Your investigation is the execution path.

What it collects

The harvest is broad. Cloud and deployment credentials for AWS, Azure, Google Cloud, Kubernetes, and Docker, plus infrastructure-management secrets. AI credentials, including authentication files for AI development tools and LiteLLM’s own stored provider keys and model config. Developer secrets and private keys: Git, GitHub, npm, PyPI, and CI/CD credentials, .env files, and SSH, GPG, and TLS keys. Browser login databases, cookies, autofill and payment data, and history. And host data: environment variables, shell and application histories, and system and network information.

Stolen data is encrypted with an AES-256-CBC key, that key is wrapped with an RSA-4096 key, and the result is uploaded to litellm[.]dev/healthcheck - a path and hostname chosen to blend into normal traffic. One of the three files, sitecustomize.py, also launches a detached loader that checks a GitHub-hosted pointer every hour and pulls Python code from an external server to run on the host. So even after the published package is gone, an infected machine keeps reaching out for new instructions.

The affected artifacts and window

The malicious PyPI release covered all seven wheels for 1.107.0 and was live from 11:39:51 to 13:23 UTC, hitting Windows, Linux, and macOS. On Docker Hub, the tags v1.107.0, latest, main-latest, and main-stable pointed to a compromised image index (sha256:1bbcb1443bc9...) from 11:46:56 to 14:20 UTC. The same tags on GHCR pointed to compromised indexes for litellm, litellm-database, and litellm-non_root from 11:46:56 UTC until they were pulled by 13:51 UTC. The reuse of latest and main-stable matters: anyone running an automated pull or a fresh deploy in that window got the bad image without asking for the specific version.

Multiple application security firms flagged the release within six minutes of publication, which is why the live windows are measured in hours rather than days.

Recovery

If you pulled 1.107.0 in those windows, treat the host as compromised, not just the package. Stop affected deployments. Inspect the environment without launching the Python interpreter, because running it re-triggers the payload. Isolate infected systems and rebuild from clean backups rather than trying to clean in place. Rotate every secret the malware could have reached - which, given the target list above, is effectively every credential present on the box, plus anything those credentials could reach. Deleting the LiteLLM package directory is not enough: the startup files sit in Python’s library directory and the hourly loader can persist independently.

The recommended clean version is 1.106.2, the last release before the attack.

This is the second time LiteLLM’s build chain has been turned against its users this year. In March, the TeamPCP group published malicious LiteLLM versions on PyPI after breaching Aqua Security’s Trivy scanner inside LiteLLM’s CI/CD pipeline. The attack surface that both incidents exploit is the same: the pipeline that signs and ships trusted artifacts is itself a credential-rich target, and a package that installs into a Python environment used for cloud and model access sits one .pth line away from everything that environment can touch.