On 21 October 2026, the popular LiteLLM Python library and proxy was compromised for the second time this year. Attackers published a malicious version 1.107.0 to PyPI and multiple container registries. The package contained a credential stealer and a remote code execution backdoor that activates automatically when any Python process starts on an affected system.
LiteLLM is widely used to route requests across different large language model providers. It sees tens of millions of downloads per week. Because the payload executes at interpreter startup, it can run even if an application never imports the litellm package itself.
What Happened
According to LiteLLM's official incident report, attackers used stolen GitHub CLI OAuth tokens belonging to three engineers. They modified the release pipeline, triggered a production release from an attacker-controlled source repository, and approved it with a second compromised account. A third account was later used to delete workflow logs.
The official GitHub tag for v1.107.0 does not contain the malicious files. The payloads were injected into the build process and appeared only in the published wheels and container images.
Timeline (UTC, 21 October 2026, per LiteLLM):
| Time | Event |
|---|---|
| 10:08 | Unauthorized changes to the release workflow were applied after branch protection was overridden. |
| 11:39–11:40 | Seven malicious litellm==1.107.0 wheels uploaded to PyPI. |
| 11:46 | Compromised Docker images published to Docker Hub and GHCR, including the mutable tags latest, main-latest, and main-stable. |
| By 13:23 | PyPI removed version 1.107.0. |
| By 14:20 | Affected Docker tags were removed or repointed to clean artifacts. |
Enterprise customers pulling only from LiteLLM's private registry were not affected. All previous versions remain safe. The recommended safe version is 1.106.2.
How the Malware Works
Researchers at JFrog, Wiz, SafeDep, Aikido, Upwind, and others analyzed the packages. Three extra files were added to the wheels and placed directly into site-packages during installation:
cook.pth— Python's site module processes.pthfiles at startup and imports the listed module.cook.py— The credential stealer (internally called "privcollect" in some reports).sitecustomize.py— Automatically loaded by Python after site processing; it forks a background daemon.
The stealer collects a wide range of secrets: cloud credentials (AWS, GCP, Azure, instance metadata), SSH and TLS private keys, browser passwords and cookies, environment variables, CI/CD and package manager tokens, Kubernetes service account tokens, and credentials stored in LiteLLM's own proxy database. It encrypts the data (AES-256-CBC + RSA) and exfiltrates it via HTTP POST to www.litellm.dev/healthcheck, a lookalike domain.
The backdoor component checks a GitHub dead-drop repository (letters9813/pythonclient-test) for a C2 domain and then downloads and executes remote Python code hourly. Marker files such as /tmp/.pc_once_* and /tmp/remote_code_loader.lock can indicate execution.
Because the hooks fire on every Python start (including pip itself), simply installing the package is enough to trigger the payload.
MITRE ATT&CK Mapping
| Technique | ID | Relevance |
|---|---|---|
| Compromise Software Dependencies and Development Tools | T1195.002 | Malicious wheels and images published through the compromised release pipeline |
| Event Triggered Execution | T1546 | .pth and sitecustomize.py hooks run on every Python interpreter startup |
| Command and Scripting Interpreter: Python | T1059.006 | Payload and second stage are Python code |
| Credentials from Password Stores | T1555 | Browser-stored passwords and cookies are harvested |
| Unsecured Credentials | T1552 | Environment variables, cloud configs, SSH keys, and CI/CD tokens are collected |
| Masquerading | T1036 | Lookalike exfiltration domain litellm.dev |
| Exfiltration Over Web Service | T1567 | Stolen data POSTed over HTTP to attacker infrastructure |
| Ingress Tool Transfer | T1105 | Backdoor downloads and executes remote Python hourly |
Impact and Indicators
Any system that installed litellm==1.107.0 via pip or pulled the listed Docker tags between roughly 11:39 and 14:20 UTC should be treated as compromised. The malware targets both developer workstations and production environments running AI proxies.
Notable indicators include:
cook.pth,cook.py, andsitecustomize.pyinsite-packages- Lock and marker files under
/tmp, including/tmp/remote_code_loader.lockand/tmp/.pc_once_* - Network traffic to
litellm.dev - The exfiltration header
X-Token: XWiA8gZNa7NcX2XRoAEb - Compromised Docker image digest
sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e(reported by LiteLLM)
This is LiteLLM's second documented supply-chain compromise in 2026. The earlier incident (versions 1.82.7/1.82.8) also involved credential theft.
Recommendations
LiteLLM and independent researchers recommend the following immediate steps:
- Check every environment with
pip show litellm(including virtualenvs and container images). If version 1.107.0 is present, assume secrets are exposed. - Delete
cook.pth,cook.py,sitecustomize.py, and any related__pycache__files from site-packages. - Kill any process holding
/tmp/remote_code_loader.lock. - Rebuild virtual environments and container images from scratch, pinning to
litellm==1.106.2(preferably by digest). - Rotate all credentials that were accessible on affected hosts: cloud IAM roles, LLM provider keys, database passwords, SSH keys, browser-stored credentials, and any secrets present in environment variables.
- Review cloud audit logs (for example CloudTrail) for unusual use of instance roles around the time of installation.
LiteLLM has revoked the involved tokens, removed all but one user from its GitHub organization, and updated registry trust relationships as temporary mitigations. Investigation into how the OAuth tokens were initially obtained is ongoing.
Conclusion
The 21 October incident shows how a compromised CI/CD pipeline can turn a high-download open-source package into a broad credential-harvesting and remote-access platform. Because the payload activates at Python startup rather than on import, traditional "did we import this library?" checks are insufficient. Organizations using LiteLLM or any AI tooling that depends on it should verify their installed versions immediately and treat any exposure of 1.107.0 as a full credential-rotation event.
Primary sources: LiteLLM official incident report (docs.litellm.ai), JFrog Security Research, The Hacker News, Wiz, and public analysis from SafeDep, Aikido, Upwind, and Flatt Security.