# LiteLLM 1.107.0 Supply-Chain Attack: A Stolen Key Turned an AI Update Into a Credential Trap

The October compromise poisoned official Python and container releases. A corrected investigation traces the breach to an exposed master key—not the early theory about Claude Code logs.

By The Signal Edition | Technology / Cybersecurity
Published: 2026-10-26T23:30:13Z
Updated: 2026-10-26T23:30:13Z
Canonical: https://www.thesignaledition.com/article/litellm-supply-chain-aihack2026102707
Image: https://www.thesignaledition.com/media/e2d87fb0d19619b3317f18034605e785.webp (Datadog Security Labs illustration of a mountain goat standing at a fork in mountain paths, one labeled LiteLLM.; credit: Datadog Security Labs; illustration accompanying its October 21, 2026 LiteLLM analysis.)

## Summary
- The October 21 compromise affected LiteLLM 1.107.0 and specified public container tags; it is distinct from March's 1.82.7/1.82.8 incident.
- LiteLLM's canonical investigation traces the attack to an exposed, unrevoked Agent Platform master key and stolen GitHub identities.
- Starting Python could activate the malware without importing LiteLLM; recovery requires clean environments and credential rotation, not merely uninstalling a package.

## A new compromise, not March replayed

The dangerous update was LiteLLM 1.107.0, published on October 21 through official Python and container channels. The Hacker News reported a credential stealer and backdoor in the release. This is distinct from the March compromise of versions 1.82.7 and 1.82.8: Datadog says no connection between the two attacks had been established at the time of its analysis. [1](https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html) [2](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/)

LiteLLM lists seven affected PyPI wheels, available from 11:39:51 UTC until 13:23 UTC. Public container tags included v1.107.0, latest, main-latest and main-stable. Affected GHCR tags were unavailable by 13:51; Docker Hub cleanup finished at 14:20. Customers pulling the private enterprise release were not affected by this incident, the company says. [3](https://docs.litellm.ai/blog/security-incident-oct-21-2026)

## The corrected root cause: a key never revoked

LiteLLM's October 23 canonical investigation starts months earlier. An Agent Platform master key was accidentally committed publicly on May 27. The commit was overwritten, but the key was not revoked. On October 10, an attacker used it to access that experimental service and obtain an organization owner's GitHub CLI OAuth token. Malicious CI workflows then extracted two maintainers' tokens. The owner-level credential enabled the attacker to override repository protections and redirect the release workflow to a lookalike repository. [4](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain)

That account supersedes early suggestions that Claude Code exposed the decisive tokens through gateway logs. The company explicitly labels some earlier assumptions inaccurate or incomplete. The confirmed chain is already serious without turning an abandoned theory into a claim about an AI tool causing the breach. [4](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain)

## Official provenance did not mean safe source

The poisoned artifacts came from Berri-AI/litellm, not the legitimate BerriAI/litellm repository. Datadog says the normal release machinery published them with apparently legitimate provenance that actually recorded the malicious fork. LiteLLM says its official GitHub source tag did not contain the malicious files. Checking the familiar project page alone therefore could miss what customers downloaded. [2](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/) [3](https://docs.litellm.ai/blog/security-incident-oct-21-2026)

## Python startup became the trigger

Microsoft found that the package planted Python startup files outside the normal LiteLLM application directory. The interpreter could launch a credential collector before an application imported LiteLLM. One observed Windows case activated it while installing an unrelated dependency. Potential exposure consequently extended beyond AI gateways to developers' machines, build agents, test environments and containers. The collector targeted accessible cloud, developer, browser and AI-tool authentication material, plus selected LiteLLM database records. [5](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/)

## What was observed—and what remains unproven

SecurityWeek reported an estimate exceeding 49,000 downloads, but downloads are not a count of compromised companies. There is concrete downstream evidence: Wiz observed attackers using stolen AWS credentials about 4.5 hours after exfiltration, including model-discovery calls consistent with LLMjacking. Separately, Microsoft's analysis did not confirm retrieval or execution of additional code through the Unix-oriented remote loader. Malware capability, observed credential abuse and a completed second-stage attack are different findings. [6](https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/) [7](https://www.wiz.io/blog/litellm-compromised-steals-credentials) [5](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/)

## Recovery starts outside the suspect environment

Microsoft advises identifying affected installations, caches, mirrors and images, isolating exposed environments, and avoiding Python or pip there during evidence collection because those commands can retrigger startup code. Rebuild from verified artifacts, rotate reachable credentials from a clean machine, revoke affected sessions and investigate subsequent identity activity. Removing the LiteLLM directory alone may leave the startup files behind. Registry takedowns stop new distribution; they do not clean systems or invalidate secrets already stolen. [5](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/)

## Reporting sources
1. [The Hacker News: LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor](https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html) (2026-10-21)
2. [Datadog Security Labs: LiteLLM supply chain compromise: What you need to know](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/) (2026-10-21)
3. [LiteLLM: Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised](https://docs.litellm.ai/blog/security-incident-oct-21-2026) (2026-10-21)
4. [LiteLLM: The attack chain behind the v1.107.0 LiteLLM release](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) (2026-10-23)
5. [Microsoft Security Research: Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/) (2026-10-23)
6. [SecurityWeek: LiteLLM Compromised in Fresh Supply Chain Attack](https://www.securityweek.com/litellm-compromised-in-fresh-supply-chain-attack/) (2026-10-23)
7. [Wiz Research: LiteLLM Compromised, Steals Credentials](https://www.wiz.io/blog/litellm-compromised-steals-credentials) (2026-10-21)