LiteLLM 1.107.0 Python Startup Hook Steals Cloud Keys and AI Tokens in 2-Hour Supply Chain Breach

A malicious release of LiteLLM version 1.107.0 was published to PyPI and container registries on October 21, 2026, according to Datadog Security Labs. The popular Python proxy library for large language models sees approximately 23 million weekly downloads, placing the compromised build in widespread use before removal. The release contained credential-stealing malware and a remote access trojan backdoor that targeted cloud, developer, and AI authentication materials across macOS, Linux, and Windows environments.

How was the legitimate build pipeline compromised?

Attackers utilized stolen GitHub CLI OAuth tokens from the accounts of three engineers to launch LiteLLM’s private release workflow, according to LiteLLM’s incident analysis. These credentials allowed the threat actors to approve and execute an unauthorized run of the legitimate build pipeline against a malicious fork named Berri-AI/litellm. This name differs from the legitimate BerriAI/litellm repository by only one hyphen, a similarity intended to evade casual human review.

The resulting wheels and container images were published through standard release channels with build provenance that recorded the malicious fork as the source. Socket researchers flagged seven malicious wheels approximately seven minutes after publication, noting that container tags including latest, main-latest, and main-stable all resolved to the same compromised image index. This extended exposure beyond deployments that explicitly pinned the version number.

What malware was installed and how does it persist?

The compromised package added three files to the victim’s Python site-packages directory: cook.pth, cook.py, and sitecustomize.py. Because Python automatically executes .pth files and sitecustomize.py during interpreter startup, the malware runs every time Python starts, regardless of whether LiteLLM is imported into the application code. Running the environment’s own python or pip commands can reactivate the malware, making routine inspection hazardous.

The cook.py script acts as a credential stealer, collecting secrets and sending them encrypted with AES-256 and RSA-4096 to a lookalike domain. The sitecustomize.py file serves as a backdoor that checks an external GitHub repository hourly for domain instructions to download and execute additional Python code. Although the remote file only held test values during observation, the mechanism allowed for potential second-stage payload delivery.

Which credentials and secrets were targeted?

The infostealer payload targeted a broad range of authentication materials, including AWS, GCP, and Azure credentials, as well as Kubernetes, Docker, Vault, and Terraform secrets. Developer-focused targets included SSH, GPG, and TLS keys, along with Git, npm, and PyPI tokens, .env files, and shell history. AI-specific targets included API keys and sessions for Claude, Codex, Gemini, Cursor, and Copilot.

If a LiteLLM proxy was configured with a database, the malware queried tables storing upstream provider credentials. Socket’s analysis identified sixteen collection modules within the payload, covering browser databases, environment variables, and developer configuration files. No evidence of successful theft from individual deployments was found at the time of the report.

What immediate remediation steps are required?

Deleting the litellm package directory does not remove the malicious files, as they persist in the site-packages directory. Users must manually remove cook.pth, cook.py, and sitecustomize.py from the affected Python installation. After removing these files, teams should revert to litellm version 1.106.2, identified as the latest safe version, and remove all code and data associated with the malicious 1.107.0 release.

From a clean machine, organizations must immediately rotate all potentially affected credentials, including cloud keys, developer tokens, and AI provider sessions. Teams should audit relevant logs for any use of exposed credentials during the two-hour exposure window. Datadog Code Security customers can use the Security Research Feed to identify affected hosts, containers, or build environments.

Detection notes

Security operations teams should monitor for unexpected outbound connections from Python processes to unfamiliar domains, particularly those resembling legitimate service endpoints. Check for the presence of cook.pth, cook.py, or sitecustomize.py in Python site-packages directories, as these files indicate infection. Look for anomalous execution patterns where Python interpreters start and immediately transmit encrypted data. Verify that build pipelines are sourcing code from expected repositories and that no unauthorized source-owner overrides have been applied to release workflows.

Background: Remote access trojans

A remote access trojan is malware that grants unauthorized users full control of your device. It disguises itself as useful software, allowing attackers to steal data, record activity, and move laterally through networks. Detection requires monitoring for unusual outbound connections and validating all software sources.

Read the full guide: Remote Access Trojans: Definition, Mechanics, and Risk Reduction

What to do and how to stay safe: LiteLLM

• Manually inspect Python site-packages directories for the presence of cook.pth, cook.py, and sitecustomize.py files, and remove them if found.
• Rotate all cloud credentials, developer tokens, and AI provider API keys that may have been accessible on systems running the compromised package.
• Revert LiteLLM installations to version 1.106.2 or earlier, ensuring that no remnants of version 1.107.0 remain in the environment.
• Audit build pipeline logs and repository access records to identify any unauthorized workflow executions or source code overrides.

General security guidance from the Firewall Scoop newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Does uninstalling LiteLLM remove the malware?

No, deleting the litellm package directory does not remove the malicious files; they must be manually deleted from the site-packages directory.

How did attackers bypass the build process?

Attackers used stolen GitHub CLI OAuth tokens from three engineers to trigger the legitimate release workflow against a malicious fork.

Was this incident connected to the earlier LiteLLM compromise?

No connection has been established between this incident and the earlier compromise affecting versions 1.82.7 and 1.82.8.