---
title: "LiteLLM supply chain compromise: What you need to know"
description: "Malicious releases of LiteLLM v1.107.0 were published to PyPI and container registries following multiple maintainer account compromises."
author: "Ian Kretz"
date: 2026-10-21
category: "emerging threats and vulnerabilities"
tags: ["software supply-chain security", "threat research", "application security"]
url: "https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/"
---

On October 21, 2026, attackers published a malicious release of `litellm`, a popular Python proxy library for LLM providers with about 23 million weekly downloads. The malicious release, version 1.107.0, was available on PyPI and in LiteLLM's official Docker images for approximately two hours before being removed. It installed a credential stealer that runs whenever Python starts and also contained a second-stage remote access trojan (RAT) backdoor. The infostealer payload targets cloud, developer, AI-tool, browser and LiteLLM proxy credentials.

This marks the second supply chain compromise of LiteLLM in 2026, with the earlier incident (affecting versions 1.82.7 and 1.82.8) being [linked](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign.md) to TeamPCP activity by Datadog Security Research. No connection between the two compromises has been established at time of writing.
| Package name | Platform | Affected releases |
| :---- | :---- | :---- |
| `litellm` | PyPI | 1.107.0 |
| `litellm` | GHCR, Docker Hub | Tags `v1.107.0`, `latest`, `main-latest`, `main-stable` |

## What happened

According to LiteLLM’s [analysis](https://docs.litellm.ai/blog/security-incident-oct-21-2026) of the incident, attackers used stolen GitHub CLI OAuth tokens from three engineers' accounts to launch LiteLLM’s private release workflow. At time of writing, it was not yet clear how the affected credentials were initially compromised.

The three stolen credentials were used to launch, approve and subsequently delete evidence of an unauthorized run of the legitimate build pipeline against a malicious fork, `Berri-AI/litellm`, whose name differs from the legitimate `BerriAI/litellm` fork by one hyphen. The similarity of the malicious fork’s name to the real project seems intended to evade casual detection by a human reviewer. The resulting wheels and images were published through LiteLLM's normal release channels and with seemingly legitimate build provenance that faithfully recorded the malicious fork as the source.

### Timeline
| Time (UTC) | Event |
| :---- | :---- |
| 11:39 | Malicious release 1.107.0 published to PyPI |
| 13:20 | PyPI quarantines affected version 1.107.0 |
| 13:53 | Affected Docker images removed |

## Payload analysis

The release adds three files to the victim Python installation’s `site-packages` directory:

- `cook.pth`  
- `cook.py`  
- `sitecustomize.py`

Python runs `.pth` files and `sitecustomize.py` automatically every time the interpreter starts. Any Python process in the environment runs the malware, **even if LiteLLM is never imported**.

- **Credential stealer (`cook.py`):** Collects secrets and sends them, encrypted with AES-256 and RSA-4096, to the lookalike domain `www.litellm[.]dev/healthcheck`.  
- Backdoor (sitecustomize.py): Every hour, checks a certain file hosted on a fixed GitHub repository (`letters9813/pythonclient-test/main/domain.txt`, now removed) for a domain, then downloads and runs Python code from it. That file only ever held test values, so no second stage payload was observed in the wild.

Deleting the `litellm` package directory does **not** remove these files. Running the environment's own `python` or `pip` triggers the malware again. Instead, the dropped payload files must be manually removed.

## Data exfiltration

- **Cloud:** AWS, GCP and Azure credentials, including from instance metadata; Kubernetes, Docker, Vault and Terraform secrets  
- **Developer:** SSH, GPG and TLS keys, Git, npm and PyPI tokens, `.env` files, shell history  
- **AI:** LLM provider API keys, and sessions for Claude, Codex, Gemini, Cursor, Copilot and other AI coding tools  
- **Browsers:** saved passwords and cookies  
- **LiteLLM proxy:** If a database is configured, it queries the tables where the proxy stores upstream provider credentials.

## What to do if you are affected

1. Manually remove the malicious `cook.pth`, `cook.py`, and `sitecustomize.py` from the `site-packages` directory.  
2. Remove all code and data associated with the malicious `litellm==1.107.0` release.  
3. Revert to `litellm==1.106.2`, the latest safe version of the package.  
4. From a clean machine, immediately rotate all affected credentials.  
5. Audit relevant logs for use of exposed credentials during the exposure window.

## How Datadog can help

[Datadog Code Security](https://docs.datadoghq.com/security/code_security/) customers can rely on the [Security Research Feed](https://app.datadoghq.com/security/feed?exposure=all&product=all&security__live=true&security__timestamp=1792611340682&sort=date&sp=%5B%7B%22p%22%3A%7B%22securityCardId%22%3A%22288%22%7D%2C%22i%22%3A%22security-news-panel%22%7D%5D&type=all) to easily identify if your environment is affected by this compromise. Use Code Security to [easily identify](https://app.datadoghq.com/security/code-security/inventory/libraries?query=library_name%3Alitellm%20library_version%3A1.107.0%20status%3AOpen&_gl=1%2A1781d5y%2A_gcl_au%2ANTU4OTIzNjkxLjE3OTE4MTMxNzg.%2A_ga%2AMTI5MjA5MDYzMC4xNzkxODEzMTc4%2A_ga_KN80RDFSQK%2AczE3OTI2MDkxMjEkbzMkZzEkdDE3OTI2MTEzMjkkajYwJGwwJGgxMTQ1MTQwODYw%2A_fplc%2Ab2tGZUpXRExLQmIzUzJhdTd3bzIyTElRUElGJTJCQ2k3MHB2SDVMM0lEU0ZMMVFOVW50QTFUalF5dWhLT0RRVWJpZUw3Yk9EMXNaRHlVaGlMa0JZRGk1ZllKUFRWd1d5WkxyMUZlaWlDMkclMkZ4eWlWdmczb3ZMTVhSNlJ0TkdkZyUzRCUzRA..&column=uniqueVulnerabilitySeverityScore&detection=runtime&group=library-version&order=desc) affected hosts, containers or build environments.

## Final thoughts

In this case, stolen developer tokens were used to point a trusted release pipeline at the wrong source. In order to ensure the validity of build provenance, it is essential to put in place adequate controls on which branches are eligible for building. Maintainers should lock release workflows to approved repositories and treat developer CLI tokens as the high-value secrets that they are.

## Indicators of compromise
| Indicator | Notes |
| :---- | :---- |
| `litellm[.]dev` | Exfiltration domain |
| `X-Token: XWiA8gZNa7NcX2XRoAEb` | HTTP header in exfiltration payload |
| `raw.githubusercontent[.]com/letters9813/pythonclient-test/main/domain.txt` | RAT dead drop |
| `/tmp/.pc_once_72129118c59f5636c0bb` | File artifact created after successful infostealer payload execution (run-once) |
| `/tmp/remote_code_loader.lock` | Lockfile: ensures only one infostealer instance runs at a time |
| `cook.pth` | Payload file dropped into `sitepackages` |
| `cook.py` | Payload file dropped into `sitepackages` |
| `sitecustomize.py` | Payload file dropped into `sitepackages` |
| `sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e` | Infected `litellm` image index |
| `sha256:7598727f209d717041db37f7dca271d3a7d328a279890e0e1d55375729aeb86d` | Malicious `litellm` macOS x86-64 .whl hash |
| `sha256:0aaf7ba346d41ef2f40390436738b001180d5a1c03aa093f121078a9969d9a1a` | Malicious `litellm` macOS ARM64 .whl hash |
| `sha256:462d0c9f67ca522d9e0e4acd245e90b36ce0d5353604a66bb7c43a1ec4a6fcf7` | Malicious `litellm` manylinux x86-64 .whl hash |
| `sha256:668169d35b87bf51324080390b1b1c5ab12bd335cfe5f1a99e3689abd5e02ae6` | Malicious `litellm` manylinux ARM64 .whl hash |
| `sha256:1bbce8caa94f01c0aaa0b7ddae51553a8a32e1ce53d96d44fe583272aff7ad00` | Malicious `litellm` musllinux x86-64 .whl hash |
| `sha256:c2e32d0ce2548aa662c18bf5001911a79fe5b30cf8357132275add02fdcde054` | Malicious `litellm` musllinux ARM64.whl hash |
| `sha256:12d4ccc5c6f8d35cf4f2cf233b7f3e418e863e657d81ff5f5fc9e210005b9484` | Malicious `litellm` Windows x86-64 .whl hash |