LiteLLM 1.107.0 Backdoored on PyPI: AI API Keys Stolen in 2-Hour Supply Chain Window

LiteLLM is an open-source Python library that provides a unified interface for calling more than 100 AI language model providers. Developers import it to route prompts to OpenAI, Anthropic Claude, AWS Bedrock, Azure OpenAI, Google Gemini, and other providers through a single standardized API. Because it handles API authentication for multiple providers, a compromised version has direct access to every AI provider credential the application uses.

The attack chain had three stages. First, attackers created or compromised the GitHub repository Berri-AI/litellm -- a lookalike of the legitimate BerriAI/litellm that differs only in a hyphen between "Berri" and "AI." They populated it with a modified version of the codebase that included the credential stealer. Second, they compromised or manipulated the litellm build pipeline to source the release from this lookalike repository rather than the legitimate one. The resulting wheel files published to PyPI and the Docker images pushed to the container registry carried the malicious code while appearing functionally identical to the legitimate release.

Third, the malicious code executes at Python interpreter startup -- not at first import, but immediately when Python initializes -- before any application code runs. This timing is deliberate: even environments that import litellm conditionally or in try/except blocks received the malicious startup code without triggering the import. The backdoor steals every accessible credential type and dispatches them to an attacker-controlled server in a single POST request, then registers an hourly scheduled task for remote code execution.

The ConnectWise Cloud Backup supply-chain attack earlier this month demonstrated the same principle for SaaS OAuth credentials. LiteLLM demonstrates it for developer toolchains: compromise a trusted library, inherit every secret the dependent application touches.

The litellm 1.107.0 backdoor systematically walked every common credential storage location accessible from the Python environment. Wiz's analysis documents the following credential categories as confirmed targets:

Any provider API key or cloud credential present in the environment during the window is now in attacker hands. The 4.5-hour turnaround to live abuse means key rotation cannot wait for a post-mortem review.

The timeline of the attack compresses the response window to near-zero for organizations running automated dependency updates.

LiteLLM's incident report places the malicious 1.107.0 package on PyPI from approximately 11:39 UTC to 13:23 UTC on October 21, 2026 -- a 104-minute window. During the same period, the Docker tags latest, main-latest, main-stable, and v1.107.0 on the GitHub Container Registry (ghcr.io/berriai/litellm) resolved to the backdoored image. Any CI/CD pipeline that ran pip install litellm (without a pinned version and hash) or docker pull ghcr.io/berriai/litellm:latest during that window installed the backdoor.

Wiz observed the first active use of stolen credentials approximately 4.5 hours after the malicious package was first available -- around 16:00 UTC on October 21. This 4.5-hour window is not a grace period; it is the time the attackers spent validating stolen keys automatically and selecting high-value targets. Organizations that installed the package at 11:39 UTC had credentials actively exploited by approximately 16:09 UTC the same day.

This is LiteLLM's second supply chain compromise in 2026. The earlier LiteLLM supply chain attack exposed CI/CD credentials across more than 430,000 pipelines. The recurrence confirms this is a targeted, persistent campaign against LiteLLM's release infrastructure, not a coincidence.

The LiteLLM 1.107.0 attack has not produced publicly disclosed C2 IP addresses or domains as of this writing. The primary indicators are version-based and behavioral. Any confirmed install of 1.107.0 is a compromise indicator; infrastructure IOCs are expected to follow from Wiz and StepSecurity research.

Version and package indicators:

• litellm==1.107.0 on PyPI
• Docker image digest matching the October 21 malicious build (see LiteLLM incident report for verified clean digests)
• Build provenance referencing github.com/Berri-AI/litellm rather than github.com/BerriAI/litellm

Behavioral indicators (post-install):

• Python subprocess launching at interpreter startup before application code executes
• Outbound POST to an external endpoint at process startup (credential exfiltration)
• A scheduled task or cron job created shortly after litellm installation
• Unexpected reads of ~/.aws/credentials, ~/.ssh/id_rsa, GOOGLE_APPLICATION_CREDENTIALS path at process start

Hunt cloud audit logs for unusual AI API calls originating from IPs outside your known CI/CD or application infrastructure, particularly OpenAI, Anthropic, and AWS API calls, starting October 21, 2026 at 11:00 UTC.

Two generated Sigma rules target the LiteLLM 1.107.0 backdoor's behavioral signatures: startup-time credential file access from a Python process and scheduled task creation immediately after package installation. Both carry experimental status; validate log field names against your endpoint telemetry schema before enabling automatic blocking.

Any environment that ran litellm 1.107.0 or pulled an affected Docker tag on October 21 must be treated as fully compromised. Do not delay rotation pending full forensic analysis -- the 4.5-hour window to live credential abuse means delayed rotation equals active attacker access to your AI providers and cloud infrastructure.

The LiteLLM attack is the second supply chain compromise targeting AI development infrastructure in 2026, and it follows a pattern that defenders need to internalize: AI libraries are high-value targets because they sit directly at the intersection of developer credentials and AI provider keys.

A developer installing litellm is implicitly granting it access to every AI API key in their environment. That is the library's purpose -- to hold and use those keys for routing. An attacker who compromises the library at build time does not need to target each developer individually. They compromise one project and inherit every key across every installation.

The scale of LiteLLM's adoption amplifies this. The library supports more than 100 AI providers and is deeply integrated into production AI pipelines, LangChain-based applications, and autonomous AI agent frameworks. Every pipeline using it as a dependency was exposed during the 2-hour window, regardless of whether it ran during that specific window, because the next run after the window could still pull the cached malicious wheel.

This is structurally identical to the earlier LiteLLM supply chain attack and to the broader pattern of PyPI supply chain attacks against developer tooling. The recurring compromise of the same project suggests the attackers have established durable access to LiteLLM's release process -- not a one-time lucky breach. Until LiteLLM provides a full post-mortem detailing the root cause and remediation, treat every future litellm release as potentially compromised and verify package hashes before installing.

The minimum viable defense for Python dependency supply chain attacks is hash pinning: every direct and transitive dependency in requirements.txt should have a hash specified via pip-compile or poetry.lock. A hash-pinned install fails loudly when the package content changes; an unpinned install silently accepts a backdoored replacement. If your CI/CD environment does not enforce hash-pinned installs for all AI libraries, the LiteLLM incident is the cost of that gap.