LiteLLM 1.107.0 was backdoored: what happened, who is exposed and what to rotate

At 11:39 UTC on 21 October 2026 a new release of LiteLLM, version 1.107.0, landed on PyPI. Within seven minutes an automated scanner had flagged every one of its seven wheels as malware. Within fifteen a security vendor had posted a public warning. Within two hours it was the biggest security story on X, in three languages, and the maintainers had declared a SEV-0.

This is the second time LiteLLM has been hijacked this year, and it is a different attack from the one in March. It is also different in kind from the default key and authentication bypass findings we wrote about in September. Those were bugs in the gateway. This is the gateway itself being replaced with a weapon, delivered through the normal install channel, with a clean git tag sitting next to it.

This post explains what happened in plain words, what the malware does, how it got into the release, who needs to act and what to do. At the end we explain why we think the gateway layer is the wrong place to carry this risk, and which Requesty controls limit the blast radius when something like this reaches a workstation anyway.

The short version

If you installed litellm==1.107.0 on any operating system, or pulled litellm/litellm:latest, main-latest, main-stable or v1.107.0 from Docker Hub or GHCR between roughly 11:40 and 14:30 UTC on 21 October, assume every credential that machine could reach has been copied. That includes the provider API keys stored inside the LiteLLM proxy database.

Safe version: litellm==1.106.2, pinned by exact version for pip and by digest for containers. The maintainers have deleted the floating Docker tags rather than repointing them, so an unpinned FROM litellm/litellm:latest will now fail to pull. That failure is the fix working.

What happened, hour by hour

Everything below comes from public sources: the GitHub issue where the incident was reported and tracked, the analyses published by JFrog, Socket, Aikido and Flatt Security, and the maintainers' own updates. All times are UTC.

The thing to notice in that table is the gap between 09:48 and 11:39. The attacker did not break into the package registry. They prepared a source tree that looked right, got the project's own release machinery to build it, and let the normal publish path do the rest. The git tag v1.107.0 on the real repository has no malicious code in it. Anyone who reviewed the tag, or the source tarball, would have found nothing except, in the tarball, one extra line of build configuration.

How the payload works

Python wheels can carry a data directory whose contents get copied straight into site-packages on install. The added data = "cook" line told the build tool to do exactly that with a hidden cook/ directory that existed only in the attacker's build tree. Three files came along:

• cook.pth is twelve bytes long and contains import cook. Python processes .pth files in site-packages every time the interpreter starts. That one line makes the next file run on every Python invocation on the machine, whether or not the program has anything to do with LiteLLM.
• cook.py is the credential stealer. It is a single line that decompresses and executes about 61 KB of Python. The decoded program calls itself privcollect.
• sitecustomize.py is the remote access backdoor. Python also imports a module by this name automatically at startup. It forks a detached daemon that wakes up every hour, fetches a domain name from the attacker's GitHub dead drop, and if one is there, runs the stealer again and then downloads and executes whatever Python the attacker's server returns. There is no signature check. Whoever controls that domain can run arbitrary code on every infected machine, indefinitely.

At the time the researchers looked, the dead drop file was empty, so the hourly backdoor was dormant. That is not reassurance. The stealer in cook.py does not depend on the dead drop and runs regardless, and the attacker can arm the backdoor later by committing a single line to a text file.

What it takes

The collector was written for developer laptops, CI runners, cloud workloads and LiteLLM proxy hosts. It gathers:

• SSH, GPG and TLS private keys, .pem, .key, .p12 and .pfx files, shell and database client history
• Saved passwords, cookies and history from Chromium browsers and Firefox
• AWS, Azure and Google Cloud credential files, plus live credentials from the cloud instance metadata services of all three
• Kubernetes configs and service account tokens, Docker configs and Swarm secrets
• GitLab Runner, Jenkins, Vault, Terraform and Packer secrets
• .git-credentials, .npmrc, .pypirc, pip, Maven, Gradle, Cargo and other package manager tokens
• Configuration and auth tokens for Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, Windsurf, Kiro, Continue, aider, goose, opencode, Cline and others
• Every environment variable of the current process and, on Linux, of every other process it can read under /proc
• The LiteLLM proxy database itself, via DATABASE_URL: it dumps LiteLLM_CredentialsTable, which holds the API key for every upstream provider the gateway talks to, and LiteLLM_ProxyModelTable

That last bullet is the one that matters for anyone running the proxy in production. A gateway exists to hold one key per provider so that applications do not have to. The malware was written with that in mind. One infected proxy host hands over the OpenAI, Anthropic, Bedrock and Vertex credentials of the whole organisation in one archive.

Everything is encrypted with a hardcoded RSA key and posted over plain HTTP to www.litellm.dev/healthcheck. The hostname was chosen so that it looks like a health check to the real project's domain in a network log. It is not.

Who is exposed

Three groups, in order of likelihood:

1. Anyone whose CI or deploy floated on a tag. pip install litellm without a pin between 11:39 and about 13:20 UTC, or any pull of the floating container tags between 11:48 and about 14:30 UTC, got the payload. Dependabot style auto-merge of the bump counts.
2. Anyone who runs the LiteLLM proxy and updated today. The proxy host has the database URL, which means the stealer got the provider keys.
3. Developers who installed it on a laptop. The laptop has the browser passwords, the SSH keys, the cloud CLI sessions and the coding agent tokens.

Two indicators tell you whether the stealer has already fired: /tmp/.pc_once_72129118c59f5636c0bb exists only after a successful upload, and /tmp/remote_code_loader.lock exists if the backdoor daemon has run. The absence of the first file does not mean you are clean, because a failed upload leaves no marker and the daemon will try again.

What to do

This is the consensus remediation from JFrog, Socket, Aikido and the issue reporters, in the order that matters.

1. Do not start with pip uninstall. Running pip starts Python, and starting Python runs the payload. Isolate the host first.
2. Kill the daemon. Look for a detached Python process whose working directory is / and which holds /tmp/remote_code_loader.lock.
3. Remove the files without Python. Delete cook.pth, cook.py, sitecustomize.py and their __pycache__ entries from site-packages, plus the two /tmp markers.
4. Rebuild rather than clean. Every vendor who decoded the sample recommends rebuilding the virtualenv, container or host from a verified image, pinned to 1.106.2 by exact version and, for containers, by digest.
5. Rotate everything in the list above. Cloud keys, SSH keys, database URLs, package publishing tokens, git tokens, coding agent tokens, browser passwords, and every provider key that was stored in the LiteLLM proxy database. Rotate the LiteLLM master key and all virtual keys too.
6. Block and hunt. Deny litellm.dev at egress, search proxy and DNS logs for it and for the GitHub dead drop URL, and check cloud audit logs for GetCallerIdentity calls from unexpected places, because the stealer validates stolen AWS credentials before shipping them.
7. Stop floating. Pin the package version in every requirements file and lock file. Pin container images by digest. Treat a release that arrives one hour after the previous one as something to look at, not something to auto-merge.

Why the gateway is where this hurts most

We made an argument in September that an AI gateway is a tier one security asset because of its position: it holds every provider key, reads every prompt, and usually carries a cloud identity. This incident is the proof. The attacker did not need to find a bug in LiteLLM. They needed to become LiteLLM for a hundred minutes, and the stealer's database module shows they knew exactly which table to read when they did.

It also shows what supply chain risk looks like when the component is self hosted. You are now responsible for:

• verifying the artifact you install matches the source you can read, which in this case it did not, and which almost nobody checks
• the patch window: fast enough that you are not running known bugs, slow enough that you are not the first to install a poisoned release
• the container's floating tags, the IAM role it runs under, the database that holds the provider keys, the egress rules that would have caught litellm.dev
• the post-mortem of a release pipeline that is private, so the people depending on it cannot audit how releases are built

None of that is routing. All of it landed on every LiteLLM operator's desk today.

What a managed gateway changes, and what it does not

Requesty is a managed gateway, so there is no gateway package in your pip install, no gateway image in your cluster and no gateway database on a host you administer. The product is written in Go and served from our infrastructure; the only thing in your code is an OpenAI compatible endpoint URL and a Requesty key. That removes the specific thing that happened today from your supply chain. It is fair to say it is not magic, so here is precisely which controls map to which part of this incident.

• Provider keys that are not on your box. With bring your own keys, your OpenAI, Anthropic, Bedrock or Vertex credentials sit in encrypted storage on our side and are attached to requests by policy. There is no LiteLLM_CredentialsTable equivalent for a stealer to dump from a host you run, and your application never holds a provider key at all.
• A stolen key is a scoped key. Every Requesty API key carries its own spend limit and rate limit, its own access list of models it may call, and an organisation wide approved models list on top. If the stealer lifts a Requesty key from a laptop's environment variables, the attacker has one credential with a monthly cap and a model allowlist, not the account.
• Rotation is an API call. The key management API and service accounts let you revoke and reissue every key a compromised host could have seen in a script, today, instead of hunting through compose files.
• You find out when a key is being abused. Spending alerts fire a webhook when a key or the organisation crosses a threshold, and the request logs show which key called which model from where. A stolen credential that starts spending at 3am is visible in minutes.
• Guardrails that catch secrets in prompts. Organisation guardrails run secret and credential scanners on requests as configuration, not as Python you upload to the gateway, so the guardrail layer is not an execution surface and does catch the API key a coding agent pastes into a prompt.
• Logging you control. Data privacy controls turn payload logging off per key or enforce zero data retention across the organisation, so a breach of any logging layer is not a breach of every conversation.

What it does not change: if a developer installs a poisoned package of any kind on their laptop, their SSH keys and browser passwords are gone, and no gateway fixes that. What the gateway decides is whether the AI credentials on that laptop are a scoped key with a cap, or the organisation's raw provider keys.

If you are comparing the two models in detail, the LiteLLM comparison page and the build versus buy piece cover the feature and cost trade offs. This post is about the risk that got repriced today.

The takeaway

LiteLLM 1.107.0 was on PyPI for about a hundred minutes and on the Docker floating tags for a bit under three hours. In that window it reached machines in every time zone, and the X conversation went from one vendor's warning to a global story in English, Japanese and Chinese before the maintainers' first update, passing 250 tracked posts by 17:00 UTC. The project has now been hijacked twice in seven months, through two unrelated paths, and the second one left the git tag spotless.

If you run LiteLLM: pin 1.106.2 by digest, check for the two /tmp markers, rebuild anything that touched 1.107.0, and rotate every provider key the proxy ever stored. Then ask whether the gateway in front of your production AI traffic should be a Python package you install, or a service whose supply chain is somebody else's full time job, with your effort going into the policies that limit what any one key can do.