LiteLLM, the open-source gateway that many teams use to route requests to dozens of language-model providers, shipped a malicious release on October 21. Version 1.107.0 landed on PyPI and in the project's Docker Hub and GitHub Container Registry images after attackers took control of its release workflow, the company said in an incident report signed by its chief executive, chief technology officer and security lead. LiteLLM says the incident is contained and that every earlier version is safe.
The exposure window was short but wide. All seven 1.107.0 wheels were downloadable from PyPI between 11:39 and 13:23 UTC. On Docker Hub, a compromised image sat behind the v1.107.0, latest, main-latest and main-stable tags from 11:46 until 14:20 UTC, while the matching GHCR tags were pulled by 13:51. Datadog Security Labs, which describes LiteLLM as having about 23 million weekly downloads, says anyone who used an unpinned install or one of those floating tags during that period may be affected. Customers on LiteLLM's private enterprise registry were not.
The payload was built to run without LiteLLM ever being imported. Each wheel dropped a cook.pth file, a cook.py stealer and a sitecustomize.py script into site-packages, so the code executed every time Python started. According to the OSV malicious-package record and Datadog's analysis, the stealer gathered cloud keys and instance metadata, SSH and GPG keys, Kubernetes, Vault and CI secrets, browser data and configuration folders of AI coding tools, encrypted them and sent them to a lookalike domain, litellm[.]dev. The second script checked hourly for a remote domain and would download and run code from it. Datadog says that control file never contained anything beyond test values, and no second-stage code was observed.
LiteLLM's account of how it happened is still preliminary. The company says the attacker held GitHub CLI tokens belonging to three developers. One token, from an organization owner, was used to override branch protection on the private release workflow and repoint it at Berri-AI/litellm, a fork whose name differs from the real BerriAI/litellm by a single hyphen. A second token cleared the production approval gate, and a third deleted the workflow records afterwards. The official 1.107.0 source tag never contained the malicious files.
Where the tokens came from is the most uncomfortable part. LiteLLM says it found an unexpected user account on an internal LiteLLM deployment that was reachable from the internet, and believes the attacker read the tokens from that deployment's logs. It adds that Claude Code can, in specific situations, include a user's GitHub CLI OAuth token in a response body, which ends up in logs when responses are recorded. The company has not confirmed how the intruder got into the deployment and suspects a recently patched vulnerability.
This is the second time this year that LiteLLM has been used to distribute malware. Back in March, the 1.82.7 and 1.82.8 releases were poisoned in a campaign Datadog links to a group it calls TeamPCP; OX Security notes that this time the tooling and infrastructure differ, and no connection has been established. The incident shows how an AI gateway, which by design sits next to every provider key an organization holds, becomes a high-value target.
The advice from LiteLLM and the security firms is blunt. Teams that installed 1.107.0 or ran an affected image should treat the host as compromised, delete the dropped files before starting Python again, rebuild environments pinned to 1.106.2 and rotate every reachable credential, including provider keys stored in the LiteLLM proxy database. LiteLLM says the investigation and its timeline are still being updated.