LiteLLM Supply Chain Attack: Backdoor Found in PyPI and Docker Packages

At 11:39 UTC on October 21, 2026, an attacker uploaded a tampered version of LiteLLM to PyPI. Less than two hours later, the cleanup began — but anyone who installed the package during that window may already have had a credential stealer and a backdoor on their systems. The LiteLLM supply chain attack is another reminder of how vulnerable AI infrastructure is to targeted compromises of its supply chain.

LiteLLM is a widely used open-source gateway from BerriAI that gives developers unified access to different LLM providers such as OpenAI or Anthropic. That central position in many AI pipelines makes the project an attractive target — and exactly why this incident deserves the full attention of developers and security teams.

Key Takeaways

• Version 1.107.0 of LiteLLM was published on PyPI on October 21, 2026 with malicious code in all seven wheel files.
• Several Docker images on GHCR and Docker Hub were also affected before being removed or repointed to clean builds.
• The malicious code consisted of three files: an automatic loader (cook.pth), a credential stealer (cook.py), and a backdoor with remote-loading capability (sitecustomize.py).
• Stolen data included cloud credentials, API keys, SSH keys, and browser logins, encrypted and sent to an external domain.
• This is already the second severe security incident at LiteLLM within seven months.

What Happened in the LiteLLM Supply Chain Attack

On October 21, 2026, an unknown attacker published version 1.107.0 of the LiteLLM package to PyPI. The release went live at 11:39 UTC. All seven wheel files of this version — the precompiled packages for Windows, Linux, and macOS — contained malicious code. That meant virtually anyone who installed the package during this window was affected, regardless of operating system.

Docker images were compromised in parallel. Affected images included:

• ghcr.io/berriai/litellm
• litellm-database
• litellm-non_root
• docker.io/litellm/litellm

This affected the tags v1.107.0, latest, main-latest, and main-stable. Anyone who pulled one of these images during the window could also have received compromised software.

The good news: the response time was comparatively fast. PyPI quarantined the malicious version around 13:20–13:23 UTC. The GHCR tags remained available until 13:51 UTC, while Docker Hub tags weren’t removed or repointed to clean images until 14:20 UTC. In total, the malicious package was actively reachable for roughly two-and-a-half to three hours — a window that, given LiteLLM’s wide use in CI/CD pipelines, is more than enough time to infect numerous systems.

“The investigation into the exact attack vector is still ongoing,” said LiteLLM security lead Oliver Jensen, an indication that full clarity on the LiteLLM supply chain attack will take more time.

Technical Details of the LiteLLM Supply Chain Attack

The injected malicious code consisted of three cooperating files. This structure is notable because it shows how deliberately the attack was engineered.

The Three Malicious Components

The file cook.pth is particularly insidious. Python automatically loads .pth files at interpreter startup, so the malicious code executes without any action from the user — a simple “pip install” is enough to trigger the infection.

The Credential Stealer in Detail

The file cook.py operates across roughly 16 modules that systematically harvest sensitive data, including:

• Browser logins and cookies from Chrome, Firefox, Edge, and Safari
• AWS credentials from the ~/.aws/ directory
• System environment variables
• EC2 and ECS instance metadata
• Google Cloud service account keys
• Azure CLI tokens
• API keys for providers like OpenAI, Anthropic, Cohere, and other LLM services
• SSH and GPG keys
• Shell history files

The collected data is then encrypted with AES-256-CBC. The encryption key itself is secured with RSA-4096 before the data is sent via HTTP POST to the domain litellm[.]dev/healthcheck. The choice of this domain name is no accident: it closely resembles the name of the original project, likely intended to avoid suspicion if network traffic was noticed at all.

The Backdoor Component

Even more dangerous than the pure data theft is the third component: sitecustomize.py. This file launches a background daemon that polls a so-called dead drop on GitHub (github.com/letters9813) every hour. Through this channel, the attacker can load and execute arbitrary Python code on the compromised system. In practice, this means the system remains permanently remote-controllable even after the initial data theft, as long as the backdoor stays active.

What Was Stolen in the LiteLLM Supply Chain Attack

The range of harvested data is unusually broad. This wasn’t a simple password theft but a systematic grab for practically every relevant credential on a developer or server system:

• Cloud access: AWS, Google Cloud, and Azure were all affected, potentially enabling broad access to entire cloud infrastructures in the worst case.
• AI provider keys: Precisely because LiteLLM acts as a gateway to services like OpenAI and Anthropic, many systems held exactly the API keys needed for daily operation of such gateways.
• Developer infrastructure access keys: SSH and GPG keys potentially grant access to code repositories, servers, and signatures.
• Browser data: Stored logins and cookies can be abused for further attacks on other services.

For organizations, this means a successful theft doesn’t have to stay contained to one system — it can become a springboard for further attacks across cloud infrastructure or third-party services.

Immediate Steps After the LiteLLM Supply Chain Attack

Anyone who installed or updated LiteLLM during the affected window should act immediately. The following steps are necessary, not optional:

1. Stop affected deployments immediately. Running instances with version 1.107.0 or the mentioned Docker tags must not continue operating.
2. Isolate systems. Block further connections until the analysis is complete.
3. Rebuild from clean backups. Simply deleting the package directory is explicitly not enough — startup files like cook.pth or the loader can remain on the system and reactivate at the next Python startup.
4. Rotate all potentially exposed credentials. This includes AWS, GCP, and Azure access, API keys for LLM providers, SSH and GPG keys, and browser logins stored on the affected system.
5. Check systems for known indicators. Specifically for the files cook.pth, cook.py, and sitecustomize.py, as well as the published image hashes of the affected Docker images.
6. Perform checks without risk. Important: checks should not be carried out by starting Python or pip inside the potentially infected environment itself, since this can trigger the malicious code again.

The recommended clean version to return to is LiteLLM 1.106.2, the last known unaffected release before the attack.

Checklist for DevOps teams:

• Version status of all LiteLLM installations checked
• Docker image tags compared against known hashes
• IOC scan performed without executing Python in the affected environment
• Affected secrets identified and rotation initiated
• Systems rebuilt from clean backup
• Network logs checked for connections to litellm[.]dev and github.com/letters9813

Context: Already the Second Incident in Seven Months

The current LiteLLM supply chain attack is not an isolated case. Just days earlier, a critical PHP security vulnerability and a Node.js security flaw involving a Brotli RCE bug triggered similar emergency patches across the developer community. In March 2026, LiteLLM was already the target of a compromise known as the TeamPCP incident. According to assessments by CloudSEK, that attack potentially affected more than 2,500 organizations and around 434,000 CI/CD pipelines. Two serious security incidents hitting the same project within just seven months raises serious questions about the security of its build and release pipelines.

For developers and security teams, this mainly means one thing: trust in a single open-source project, no matter how widely used and established, is no substitute for your own verification. Especially for components deeply embedded in production pipelines with access to sensitive credentials, it should be standard practice not to blindly adopt version updates, but to run them through staging environments and integrity checks first.

Conclusion and Next Steps

The LiteLLM supply chain attack of October 21, 2026 shows clearly how quickly a compromised package source can turn into a serious security crisis. Within a few hours, credentials for cloud services, LLM providers, and developer infrastructure were potentially harvested, encrypted, and exfiltrated via a deceptively authentic-looking domain. The added backdoor functionality makes the incident even more severe, since affected systems can remain remote-controllable even after the initial data theft.

Developers and DevOps teams using LiteLLM should immediately check whether their systems were updated during the affected window. When in doubt, it’s better to rebuild a system and rotate credentials one time too many than to leave a compromised system running unnoticed. Given that this is already the second incident within seven months, a fundamental review of your own supply chain security for AI infrastructure is advisable — regardless of which gateway or framework you actually use.