Version 1.107.0 of LiteLLM, the open-source gateway that routes requests to dozens of AI providers, was published to PyPI on October 21 carrying a credential stealer and a remote-access backdoor in every compiled wheel, according to independent analyses by several security firms. All seven wheels — for Linux, macOS and Windows — install the same three extra files, and both payloads run whenever any Python process starts on the machine, even one that never imports LiteLLM itself. PyPI has since removed the release, and the official Docker image for the same version is compromised as well.
LiteLLM sits in an unusually sensitive position: a proxy deployment holds the API keys for every provider it routes to. That is the same exposure pattern behind the OpenCode console breach that exposed OpenAI, Anthropic and Google API keys, and it is why a poisoned release of this particular package matters well beyond one project’s users.
How The Implant Got Into The Wheels
The malicious files are not in LiteLLM’s GitHub source. SafeDep’s analysis found that the source distribution’s pyproject.toml carries one extra line in its maturin build section — data = “cook” — which tells the build tool to copy a cook/ folder into the wheel’s data section. That folder does not exist in the source tarball or on GitHub; it was created in the build environment, and its contents landed in site-packages on install, listed with valid hashes in the wheel’s own RECORD manifest.
The three planted files are cook.pth, cook.py and sitecustomize.py. SafeDep assessed with moderate to high confidence that BerriAI’s private release pipeline built the wheels from an attacker-modified source, possibly through a compromised maintainer or bot credential; how the pipeline was reached remains unconfirmed, and the researchers analysing the October incident have not named any actor behind it.
What The Stealer Takes, And Where It Sends It
Because Python executes import lines in .pth files at every interpreter startup, the 12-byte cook.pth — containing only “import cook” — runs the stealer in every Python process on the host: the application, pip, IDE language servers and CI jobs alike. The stealer, a roughly 61 KB obfuscated payload, collects SSH keys, cloud credentials for AWS, Azure and Google Cloud (including live instance-metadata credentials), browser passwords and history, CI/CD secrets, Kubernetes and Docker credentials, and the configuration and tokens of AI developer tools including Claude Code, Cursor, GitHub Copilot, Windsurf, Gemini CLI and Codex.
It also reads the LiteLLM database directly, dumping the tables that store a proxy’s provider API keys and model configurations — the exact secrets a LiteLLM deployment exists to hold, and the kind of material developers manage through tools such as Claude Code and the other assistants whose credentials the stealer separately targets. Collected data is encrypted and posted to an attacker-controlled domain, www.litellm.dev, which is not affiliated with the LiteLLM project; a marker file ensures the stealer collects only once per host.
The Backdoor That Phones Home Every Hour
The third file, sitecustomize.py, is the persistence mechanism. Python imports sitecustomize automatically at startup, and this copy forks a detached background daemon that, every hour, reads a server address from a file in an attacker-controlled GitHub repository, re-runs its embedded stealer, and downloads and executes whatever Python code the current server address serves. That gives the attacker arbitrary code execution on every infected machine, indefinitely, with the privileges of whatever Python process is running.
Containment moved quickly once researchers published: PyPI quarantined version 1.107.0, the Docker image was removed from Docker Hub and GHCR, and GitHub took down the attacker’s repository, leaving the backdoor with no server address to read. Anyone who installed litellm==1.107.0 from a wheel, or ran the 1.107.0 Docker image (including via the latest tags), should assume credentials on that machine are compromised, check for the marker files /tmp/.pc_once_* and /tmp/remote_code_loader.lock, and rotate the exposed secrets. Versions 1.106.2 and the 1.107.0 release candidates are reported clean, as are the companion packages the release pins.
Why It Matters
LiteLLM is infrastructure, not an app: it is the layer through which thousands of teams reach OpenAI, Anthropic, Google and other providers, which means one poisoned wheel harvests not one product’s password but the keys to a company’s whole AI stack. The attack also bypassed the defences teams actually rely on — the GitHub source was clean, a dependency diff against the previous release candidate showed nothing unusual, and the implant arrived inside a correctly built, correctly hashed official wheel. For the developer-tools industry covered in our explainer on AI coding tools, this is the second LiteLLM compromise this year, after versions 1.82.7 and 1.82.8 were poisoned in March, and it lands in the same week that AI tooling credentials keep surfacing as the target rather than a bystander.
Background
LiteLLM, built by BerriAI, became the default open-source proxy for calling more than a hundred model providers through one OpenAI-compatible interface, and its proxy deployments concentrate provider API keys in a single database by design. Its March 2026 compromise, in which attackers used a publishing token stolen in a wider supply-chain campaign, made it an early example of AI infrastructure as a supply-chain target; the October incident uses a different injection route — a build-configuration line rather than a stolen token — but aims at the same concentrated store of secrets.
0 Comments