LiteLLM 1.107.0 Supply Chain Attack: Timeline, Stolen Data and a Response Checklist

On 21 October 2026, LiteLLM 1.107.0 was published to PyPI and to the project’s Docker image tags with a credential stealer inside. LiteLLM says its own release pipeline was compromised. If 1.107.0 ever ran in your environment, treat every secret that host could read as stolen. The last safe version is 1.106.2, and PyPI has removed 1.107.0.

This post covers what the sources say, where they disagree, and a checklist you can work through today. The full record sits in our LiteLLM 1.107.0 incident profile.

What Happened to LiteLLM on 21 October?

LiteLLM’s own incident post says version 1.107.0 contained compiled malware that steals credentials and loads remote code tools. Seven wheels, covering Linux, macOS and Windows, went to PyPI between 11:39:51 and 11:40:13 UTC. The affected Docker tags were v1.107.0, latest, main-latest and main-stable. LiteLLM also says the official v1.107.0 source tag on GitHub does not contain the malicious files, and that its enterprise private release was not affected.

This is the second LiteLLM supply chain incident this year. In March 2026, two other versions were published with a stealer, as covered in our LiteLLM PyPI package compromise profile and the Trivy pipeline lessons post. The October release took a different route, described below.

How Did the Bad Release Get Built?

LiteLLM says three engineers’ GitHub accounts were used, which it says appears to be through stolen GitHub CLI OAuth tokens. One account changed the private release workflow and triggered the run. A second approved the production step. A third deleted workflow records. LiteLLM says it has not yet found how the tokens were obtained.

Socket and Wiz add that the staging build ran from a lookalike repository, Berri-AI/litellm, one hyphen away from the real BerriAI/litellm. SafeDep adds that a build setting added a folder named cook to the wheels but not to the source archive. SafeDep rates as moderate to high confidence that the wheels came from attacker-modified source built by the project’s own pipeline. That is an assessment, not a confirmed finding.

The steps above merge what LiteLLM, Socket, SafeDep and Wiz each describe. The MITRE ids are Socket’s mapping. Our related Compromise Software Supply Chain page covers the wider technique.

What Does the Malware Do?

The wheels install three files into site-packages: cook.pth, cook.py and sitecustomize.py. The .pth file runs at every Python start, so the stealer runs even in programs that never import litellm. That is the technique MITRE calls Python Startup Hooks. Socket warns that sitecustomize.py can be a legitimate file, so the name alone is not proof.

Per Socket, the stealer reads cloud and deployment credentials for AWS, Azure, Google Cloud, Kubernetes, Docker, GitHub CLI, Vault and Terraform. It also reads Git, npm and PyPI config, .env files, SSH, GPG and TLS keys, AI tool credential files, browser data and shell histories. When a database URL is set, it queries the LiteLLM proxy tables that hold provider keys. That matches MITRE’s Credentials in Files.

The data is encrypted and posted to www.litellm[.]dev/healthcheck. The sitecustomize.py file starts a detached loader that reads a domain from a GitHub dead-drop file and runs code fetched from that domain every hour. StepSecurity says the loader fails silently on Windows, while the stealer still runs. Wiz reports that the dead-drop file was never populated beyond test values, and SafeDep says the account hosting it was later deleted.

Which Times Do the Sources Agree On?

LiteLLM gives the most detailed times, and we use them here. Others differ in small ways. Wiz writes that PyPI quarantined the release “as of 1:20 UTC”. That is before the 11:39 upload, so it most likely means 13:20 UTC. Wiz also says the images were gone around 13:53 UTC. StepSecurity says BerriAI confirmed the images removed at 14:32 UTC. Socket dates the first build run at 10:51 UTC, while LiteLLM dates its staging build at 10:46 UTC.

What Should You Do Now?

Work from LiteLLM’s guidance, with Socket and StepSecurity for detail. The order below follows StepSecurity, which stops the loader before deleting the files. The order matters: do not run pip install in a suspect environment first, because Python startup re-runs the malicious files.

A /codepy request means second-stage code ran, and the scope of the incident is larger. Block litellm[.]dev at DNS or egress and alert on the dead-drop address. Wiz reports that about 4.5 hours after exfiltration the attacker tested stolen AWS instance role credentials and listed Bedrock models, which Wiz calls consistent with LLMjacking. Check your cloud audit log for that pattern, and see our guide on how to respond to leaked credentials.

What Do Public Posts and Underground Channels Show?

We counted public posts on X mentioning LiteLLM on 21 October 2026. The 169 newest unique posts, written between 15:52 and 20:04 UTC, are mostly in English (121), with 19 in Chinese. Volume peaked at 19:00 UTC. Nine of the posts appear to share indicators. The outside page linked most often is SafeDep’s write-up, with 11 links.

In the underground chat and forum sources we monitor we found 60 posts that mention LiteLLM between 21 September and 21 October 2026, 57 of them on Telegram. 24 are dated 21 October. We cannot tell from counts who read the stolen data or what was done with it. Keys that leave a company can later appear in stealer logs or for sale, which is the kind of exposure our leaked credential monitoring page describes.

What Should Teams Change After This?

Three points stand out in LiteLLM’s account of the incident. First, branch protection that one privileged credential can override is not a control against stolen tokens. Second, approval by a second credential is weaker than it looks if both tokens can be stolen. Third, a clean GitHub tag does not make the package clean, so compare what you install with the source it claims to come from.

For your own pipelines, pin dependencies and image digests, and keep release credentials apart from dependency installs and tests. For the wider picture, read our supply chain attack and malicious package entries. Our earlier analysis of AI gateway exploitation explains why model provider keys on gateways are a target. Today, search your lockfiles and run the checklist above.