The LiteLLM Supply-Chain Compromise: What the Injected Code Did and How to Check Your Deployment

LiteLLM is a widely used Python library and proxy that gives applications one interface to many AI model providers. According to LiteLLM's incident notice, the release v1.107.0, published on October 21, 2026, contained compiled malware that steals credentials and loads remote-code-execution tools.

This article explains what the injected code did, how the attackers reportedly got in, and which checks make sense for your own environment. It relies on reports from LiteLLM, Microsoft and Datadog, and the investigation was still being updated as of October 23, 2026.

What the Injected Code Did

The malicious package used Python startup mechanisms to run automatically. Microsoft reports that simply starting Python in an affected environment could be enough, even if the application never imported LiteLLM. That matters because the exposure was not limited to production servers: developer workstations, CI/CD agents, test environments and containers were all potentially affected.

The credential stealer

Datadog describes a stealer named cook.py. It collected secrets, encrypted them with AES-256 and RSA-4096, and sent them to the lookalike domain www.litellm[.]dev/healthcheck. The domain is written here in defanged form, so do not visit it.

Reported targets include:

• AWS, GCP and Azure credentials, including those from instance metadata (the local service a cloud VM queries for its own role credentials)
• Kubernetes, Docker, Vault and Terraform secrets
• Developer credentials, browser data, SSH material and environment variables
• LiteLLM database data accessible to the affected process

In practice, anything the Python process could read was in scope. A CI runner holding a cloud deploy token is as exposed as a laptop with SSH keys.

The persistent backdoor

Datadog also describes a sitecustomize.py backdoor. Python imports a file with that name automatically at startup, which makes it a convenient hiding place. The backdoor checked hourly for a domain stored in a file at letters9813/pythonclient-test/main/domain.txt on GitHub, then downloaded and ran Python code from that domain. Datadog's report says that file has since been removed, so the second stage can no longer be inferred from it, but a machine that ran the backdoor may already have executed whatever it fetched.

How the Attackers Got In

LiteLLM's attack-chain post describes a chain that began months earlier. On May 27, 2026, a configuration file containing the master key to a LiteLLM Agent Platform deployment was committed publicly to the LiteLLM-Labs/lite-harness repository. The key was never revoked.

On October 10, the threat actor used that key to access the platform and extract a GitHub CLI OAuth token. They then obtained similar tokens tied to two engineers with maintainer privileges. The lesson is general: a leaked secret that is not rotated stays dangerous for months, and publishing rights on a package are only as safe as the tokens behind them.

How to Check Your Deployment

Start with the installed version. LiteLLM's guidance includes this command, which you should run in every environment that might have installed the package, including containers and CI images:

pip show litellm

If the reported version is 1.107.0, treat the environment as compromised. Because the code could run at interpreter startup, also check build caches and images that were created while that version was available, not only running services.

Next, look for the reported artifacts. A basic search for the files named in the research can help, though a clean result is not proof of safety, since attackers can rename files:

find / \( -name cook.py -o -name sitecustomize.py \) 2>/dev/null
pip cache list 2>/dev/null | grep -i litellm

A sitecustomize.py file is not malicious by itself, so inspect any hit rather than deleting it blindly. Also review DNS and proxy logs for connections to litellm[.]dev.