LiteLLM 1.107.0 Supply Chain Poisoning: Credential Theft and Backdoor Response Guide

Incident Overview: A Window of Under Two Hours Is Enough to Create Lasting Risk

The PyPI package for LiteLLM, an open-source LLM gateway, was confirmed to contain credential-stealing code and backdoor logic in version 1.107.0 less than two hours after release, and was subsequently taken down. What matters in a supply chain poisoning incident like this is not the length of exposure, but two things: the probability that the malicious version was installed, and the irreversibility of credential leakage once installed. Two hours is enough for CI/CD pipelines, automated image builds, and dependency lock file updates to pick it up—and once an API key leaks, attackers don't need to maintain a persistent presence to use it long-term.

Based on official disclosures and community verification, this article lays out three actions: confirm whether you are affected, clean up local and build environments, and rotate exposed credentials. For teams using LiteLLM as a unified entry point for multiple models, this must be handled as a security incident response—not a routine upgrade.

First, Determine the Scope: Who Might Have Installed the Malicious Version

Determining Versions and Installation Channels

The affected release is 1.107.0 on PyPI. What needs checking is not just developer environments that ran pip install litellm directly, but also:

• Projects whose lock files or dependency resolution results landed exactly on 1.107.0 (including indirect dependencies)
• Container images and CI build artifacts rebuilt during the incident window
• Internal private sources and artifact repositories that cached or mirrored this version
• Developer machines and experimental environments using auto-upgrade policies

Use pip show litellm, pip freeze | grep litellm, or project lock files to check. For container environments, verify the actual installed version in the image layers rather than relying solely on what the build script declares.

Supply Chain Poisoning refers to attackers implanting malicious code by tampering with legitimate components in the software distribution chain—such as published packages on public package indexes, build tools, or dependency libraries—rather than directly attacking the target system. Unlike traditional vulnerability exploitation, poisoning relies on developers' trust in upstream components: as long as someone installs or pulls a contaminated version, the malicious code executes automatically during normal build or runtime processes. Public repositories like PyPI and npm, with their open publishing mechanisms, are high-incidence areas for such attacks. Defenses should focus on pinning dependency versions and verifying hashes, delaying adoption of new releases, and auditing changes to critical dependencies—thereby reducing the probability that the "release window" is automatically captured.

Why "Upgrading to the New Version" Does Not Equal Safety

The malicious code has already executed. Upgrading only prevents future execution; it does not undo credential reads that already occurred. Therefore the order should be: gather evidence first, then clean up, and finally rotate—avoid overwriting evidence before it is collected. In practice, prioritize recording the list of affected hosts, images, and build pipelines as the basis for the subsequent rotation scope.

Cleanup Priorities: From Credentials to Environments

First Priority: Rotate All Keys That Could Have Been Read

LiteLLM's role means it can touch a large number of high-value credentials: API keys for various model providers, access tokens for proxy services, and other environment variables injected into the deployment environment. Credential-stealing malware typically reads environment variables and configuration files directly, so the rotation scope should be based on "what existed in that environment," not "what LiteLLM theoretically needs."

The rotation checklist should cover: model provider API keys, cloud provider access keys, database and cache connection strings, internal service-to-service tokens, CI/CD platform secrets, and any third-party tokens that appeared in the affected environment. After rotation, check usage and call logs across platforms for anomalous call sources—especially egress IPs or call patterns that would not normally appear.

Credential Rotation means revoking old keys and issuing new ones after a key leak is suspected or confirmed, invalidating the leaked old values. For credential-stealing malware, rotation is the only way to cut off an attacker's long-term access—because attackers often use stolen keys offline and do not rely on persistent presence. Rotation should follow the principle of "over-covering rather than under-covering": base the scope on keys that actually appeared in the affected environment, not what the component theoretically requires. Rotation must be accompanied by call log audits to check for requests from anomalous IPs, at unusual times, or with unusual patterns—confirming whether the leak has been exploited and determining whether to further expand the rotation scope.

Second Priority: Rebuild Rather Than Patch Environments

For machines and images confirmed to have installed the malicious version, rebuilding directly is recommended. The presence of backdoor logic means attackers may have further delivery capabilities, and cleaning individual files is insufficient to restore a trusted state. This includes developer machines, build nodes, container images, and any test environments that ran this version. Also clear the corresponding version from package manager caches and private artifact repositories to prevent reintroduction during rollbacks.

Backdoor refers to a covert mechanism implanted by attackers to bypass normal authentication or maintain persistent control. Unlike one-time credential-stealing code, a backdoor may include capabilities for remote command delivery, scheduled callbacks, or secondary payload loading. This means that even after deleting known malicious files, attackers may regain access through other residual mechanisms. Therefore, the standard security practice for environments confirmed to have run a backdoored version is "rebuild, don't patch": redeploy from a trusted baseline, completely discard potentially tampered systems and images, and clean the corresponding versions from artifact repositories to prevent reintroduction via rollback or cache.

Third Priority: Tighten Dependency Policies

The incident exposes a general problem: directly depending on public package indexes while allowing automatic resolution of the latest version transmits the risk of the release window straight into the production chain. Feasible improvements include using lock files with hash verification, setting internal audit and delayed-adoption policies for critical dependencies, and performing manual or automated review of new dependency changes. For components like LiteLLM that sit at the center of the call chain, also restrict the range of keys accessible from their runtime environment, reducing the blast radius of a single point of leakage through least privilege.

Implications for the AI Engineering Stack

Gateway Components Are High-Value Targets for Supply Chain Attacks

Unified access layers like LiteLLM naturally hold credentials for multiple providers and are typically deployed where they can reach both internal networks and external APIs. Attackers don't choose them by accident: a single successful poisoning can grant access to multiple model services at once, and such tools often have weaker observability than core business services. When adopting such tools, teams should treat them as sensitive infrastructure subject to the same security requirements as databases and key management services.

Actionable Detection and Response Capabilities Are Needed

In this incident, the version number was the only reliable signal—which itself says something: without dependency inventories, build provenance, and credential usage audits, teams struggle to define the impact boundary after the fact. A more practical approach is to incorporate "dependency change detection" and "anomalous credential usage detection" into daily monitoring, shortening the response to similar incidents from "days of investigation" to "executing a checklist."

Action Checklist

1. Check the LiteLLM version in all environments and images, and flag any hits on 1.107.0.
2. Rotate all credentials in affected environments and audit call logs across platforms.
3. Rebuild affected hosts and images, and clean the corresponding version from artifact repositories.
4. Strengthen dependency pinning and audit processes, and narrow the key access scope of gateway components.

The principle for handling supply chain poisoning is not complicated: treat it as a credential leak that has already occurred, not as a version upgrade that needs to be rolled back.

One-line Summary

LiteLLM 1.107.0 was supply chain poisoned—investigate, rebuild, and rotate keys as a credential leak incident.