LiteLLM 1.107.0 Compromised: Credential Stealer and Backdoor Found

Critical Supply Chain Attack Hits LiteLLM: What You Need to Know

A severe supply chain attack has compromised LiteLLM version 1.107.0 on the Python Package Index (PyPI), one of the most widely used open-source libraries for accessing large language models. Security researchers at SafeDep, StepSecurity, and Aikido have confirmed that the malicious release contained a sophisticated credential stealer and an hourly remote code execution backdoor, posing an immediate threat to developers, CI/CD pipelines, and AI infrastructure.

The compromised package, published on October 21, 2026, was downloaded by thousands of developers before PyPI quarantined it within two hours. However, the damage may already be done, as the malware is designed to exfiltrate sensitive credentials from infected systems.

TL;DR: The Impact at a Glance

• Compromised Package: litellm==1.107.0 on PyPI
• Malware: Credential stealer (cook.py) and remote code loader (sitecustomize.py)
• Execution: Runs automatically on every Python interpreter start, no import required
• Targets: SSH keys, cloud credentials, browser passwords, AI tool tokens, and LiteLLM proxy API keys
• Status: Release removed from PyPI; Docker images also pulled
• Action Required: Rotate all credentials and rebuild affected environments from trusted sources

How the Attack Works: A Deep Dive into the Malware

The malicious litellm-1.107.0 wheels contained three extra files that were installed directly into the root of site-packages: cook.pth, cook.py, and sitecustomize.py. The critical design flaw is that Python automatically executes .pth files and sitecustomize.py on every interpreter startup, meaning the malware runs regardless of whether LiteLLM is ever imported by the application.

Payload 1: The Credential Stealer (cook.py)

The cook.pth file contains a single line, import cook, which triggers the execution of cook.py. This 22KB Python file contains obfuscated code that, when decoded, reveals a sophisticated credential-stealing module called privcollect. Security researchers note that the stealer targets a wide range of sensitive data:

• Cloud Credentials: AWS, Google Cloud, Azure, Kubernetes, and Docker configurations
• Developer Secrets: SSH keys, GPG keys, TLS private keys, and shell history
• AI Tool Tokens: Claude, GitHub Copilot, Cursor, and 20+ other AI development tools
• Browser Data: Saved passwords and browsing history from Chrome, Firefox, and other browsers
• LiteLLM Proxy Database: The LiteLLM_CredentialsTable and LiteLLM_ProxyModelTable, which contain LLM provider API keys
• CICD Secrets: GitLab runner configs, Jenkins credentials, and Terraform tokens

The stolen data is encrypted using a hybrid scheme: AES-256-CBC for the payload and RSA-OAEP with an embedded 4096-bit public key for the session key. The encrypted bundle is then sent as a tar.gz file to the lookalike domain www.litellm.dev via a POST request to /healthcheck with a hardcoded bearer token.

Payload 2: The Hourly Backdoor (sitecustomize.py)

The second payload, sitecustomize.py, is arguably more dangerous. It forks a background daemon that detaches from the parent process and runs every hour. The daemon performs the following actions:

1. Reads a command-and-control (C2) server address from a GitHub repository (letters9813/pythonclient-test)
2. Runs the embedded credential stealer again (without the once-per-host marker)
3. Downloads and executes arbitrary Python code from the C2 server

This architecture gives the attacker full remote access to infected systems. While the GitHub account was deleted hours after the attack, any host that ran the daemon before deletion may have already received and executed second-stage payloads, potentially including ransomware or other destructive tools.

The Attack Vector: How the Malware Got In

Investigators found that the source distribution (sdist) of litellm-1.107.0 contained a single suspicious line in the pyproject.toml file under the [tool.maturin] section: data = "cook". This directive instructed the build system to copy the cook/ folder into the wheel, which pip then installs into site-packages.

SafeDep's analysis revealed that the release source did not match the corresponding git tag v1.107.0. Instead, the sdist was based on a later main-branch commit (a8113b0) with several modifications, including the version reversion to 1.107.0 and the injection of the data = "cook" line. The researchers assessed with moderate-to-high confidence that the attacker had access to BerriAI's private release pipeline, suggesting a compromised maintainer credential or a malicious insider.

Timeline of the Attack

All times are UTC on 2026-10-21:

• 06:59 - Tag v1.107.0 created, but declares version 1.108.0
• 08:50 - Legitimate main-branch commit a8113b0 created
• 08:56 to 10:46 - Ten attacker commits layered over the legitimate commit
• 11:20 to 11:37 - Malicious wheels built (macOS, Linux, Windows)
• 11:39 to 11:40 - 1.107.0 uploaded to PyPI
• 11:50 - GitHub release v1.107.0 published by bot
• 12:06 - Compromise reported to LiteLLM maintainers
• 13:23 - Version removed from PyPI
• 13:40 - Attacker's GitHub account deleted
• 13:50 - Maintainers acknowledge incident as SEV-0
• 14:32 - Malicious Docker images removed

The speed of PyPI's response and the maintainers' acknowledgment is commendable, but the window of exposure was significant. LiteLLM has over 92 million monthly downloads, making this one of the most impactful supply chain attacks of the year.

Why This Matters: The AI Supply Chain Risk

This incident highlights a growing trend: attackers are increasingly targeting AI infrastructure. LiteLLM is not just a developer convenience; it's a critical component of AI gateways that manage API keys for OpenAI, Anthropic, Azure, and other major LLM providers. A compromise of this library gives attackers direct access to the keys that power enterprise AI applications.

This is the second time LiteLLM has been compromised this year, following the March incident involving versions 1.82.7 and 1.82.8. The recurrence suggests that the project's release pipeline has persistent security gaps that attackers are actively exploiting.

Indicators of Compromise (IOCs)

System administrators and security teams should immediately check for the following indicators:

Network Indicators

• POST requests to www.litellm.dev/healthcheck
• HTTP header X-Token: XWiA8gZNa7NcX2XRoAEb
• Requests to raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt
• Outbound connections to 169.254.169.254 (AWS metadata service) from Python processes

Host Indicators

• Presence of cook.pth, cook.py, and sitecustomize.py in site-packages
• Files /tmp/.pc_once_72129118c59f5636c0bb and /tmp/remote_code_loader.lock
• Environment variable PRIVCOLLECT_ACTIVE=1
• Detached Python daemon processes (parent PID 1, own session)

Recovery and Mitigation Steps

Security experts from Aikido and Wiz recommend the following immediate actions for anyone who may have installed the compromised version:

1. Assume compromise: Treat all systems that installed litellm==1.107.0 as fully compromised.
2. Rotate all credentials: Revoke and rotate cloud keys, SSH keys, browser sessions, repository tokens, and AI service credentials from a clean system.
3. Rebuild environments: Do not simply reinstall LiteLLM; rebuild affected environments from trusted sources and pin container deployments to verified image digests.
4. Review logs: Check cloud and source control logs for unexpected access after the installation date.
5. Scan for IOCs: Use the indicators above to identify other potentially infected systems.

The latest safe version of LiteLLM is 1.106.2, according to Wiz's analysis. The release candidates 1.107.0rc1 and rc2 are also confirmed clean, as are the companion packages litellm-proxy-extras==0.4.110 and litellm-enterprise==0.1.78.

The Bottom Line

The LiteLLM compromise serves as a stark reminder that open-source software, no matter how reputable, is not immune to sophisticated supply chain attacks. The incident underscores the need for rigorous security practices in AI infrastructure, including verifying package integrity, using provenance attestations, and maintaining comprehensive credential rotation policies.

As the AI ecosystem continues to grow at breakneck speed, the security community must remain vigilant. Attackers are clearly targeting the tools that developers trust most, and the LiteLLM incident is likely not the last of its kind. Organizations should treat this as a wake-up call to audit their entire software supply chain, not just the applications they build, but the libraries and frameworks that underpin them.