LiteLLM supply chain compromise: What you need to know

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 to TeamPCP activity by Datadog Security Research. No connection between the two compromises has been established at time of writing.

What happened

According to LiteLLM’s analysis 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

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 customers can rely on the Security Research Feed to easily identify if your environment is affected by this compromise. Use Code Security to easily identify 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