One Unrevoked Key, Five Months Later: How LiteLLM 1.107.0 Shipped a Credential Stealer

The most-used piece of plumbing in many AI stacks is not a model. It is the thin layer that sits between your code and the model providers. LiteLLM, an open-source Python SDK and proxy that puts OpenAI, Anthropic, Bedrock, Vertex and dozens of other APIs behind one interface, is a good example. Socket, quoted by Help Net Security, puts its downloads at about 23 million a week. On 21 October 2026 a malicious version, litellm==1.107.0, was published through LiteLLM’s own release pipeline, with valid signatures and provenance.

On 23 October LiteLLM published what it calls its canonical postmortem. It corrects a good part of the company’s first account and traces the incident back to a mistake made five months earlier. The story is worth reading closely: the attack used no novel exploit, and every control it got past is one that many teams also rely on.

What was published, and for how long

According to LiteLLM and the security firm StepSecurity:

PyPI: all seven 1.107.0 wheels (macOS, Linux glibc/musl, Windows) were live from 11:39:51 UTC to about 13:23 UTC on 21 October.
Containers: the v1.107.0, latest, main-latest and main-stable tags of litellm/litellm on Docker Hub and of ghcr.io/berriai/litellm (plus the -database and -non_root variants) served the payload from 11:46:56 UTC until 13:51 UTC (GHCR) and 14:20 UTC (Docker Hub).
The official v1.107.0 git tag is clean. The build was pointed at a lookalike repository, Berri-AI/litellm (note the hyphen), instead of the real BerriAI/litellm.
The last known-good release is 1.106.2. LiteLLM says enterprise customers pulling from its private registry were not affected.

That window is short, but latest tags and unpinned pip install litellm in CI jobs are exactly the cases that pick up a new release within minutes.

What the payload did

StepSecurity’s analysis shows the wheels installed three extra files into site-packages:

cook.pth, 12 bytes: import cook. Python runs .pth files at every interpreter start, so the code ran even on machines that never imported litellm. Any Python process in that environment, a test runner or a linter for example, set it off.
cook.py, a stealer that labels itself privcollect, with 16 collection modules. It targets SSH and GPG keys, AWS/Azure/GCP credentials and instance-metadata role credentials, ~/.kube/config, Docker, npm, PyPI and git credentials, .env files, Vault and CI tokens, browser passwords and cookies, and every process’s environment via /proc/<pid>/environ. It also looks for tokens belonging to AI coding tools such as Claude Code, Cursor, Copilot, Gemini CLI and Codex.
sitecustomize.py, a loader that forks a daemon, reads a hostname from a GitHub “dead drop” every hour, then fetches and exec()s Python from http://<host>/codepy. That gives the attacker remote code execution that persists after the theft.

The stolen data was encrypted with AES-256 under a key wrapped with an embedded RSA-4096 public key, then POSTed to www.litellm.dev, a domain registered on 13 October. As StepSecurity notes, a packet capture therefore cannot tell victims what was taken. In the litellm-database image a module went further and queried the proxy’s own tables of upstream provider API keys. Socket is more cautious about this part: the code shows intent, not proven success against any particular deployment.

Wiz, cited by Help Net Security, saw the stolen data being used: about four and a half hours after exfiltration the attacker started validating AWS credentials and checking Amazon Bedrock access. That pattern is called LLMjacking, meaning running up model bills on someone else’s account. No threat actor has been publicly named.

The real root cause: a key nobody revoked

LiteLLM’s first post, on 21 October, suspected that tokens were lifted from the logs of an internet-exposed internal deployment, possibly through a recently patched vulnerability. The 23 October postmortem replaces that account:

27 May 2026: an opencode.json config file committed to the public LiteLLM-Labs/lite-harness repo contained the master key for a deployment of the experimental LiteLLM Agent Platform, described as an internal alpha service for self-hosted agents that file PRs. In the postmortem’s words: “the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key.”
10 October: the attacker used that key against the Agent Platform API, which returned the GitHub CLI OAuth token of one of LiteLLM’s two GitHub organization owners. The token “was not associated with a service account and was not scoped down.”
Same evening: with owner rights, the attacker pushed temporary CI branches whose workflows posted repository secrets to webhook.site. Among them were two more maintainers’ GitHub tokens, stored as GH_TOKEN and RELEASE_PLEASE_TOKEN. A second round on 12 October collected secrets from several private repos.
21 October: branch protection rejected an unauthorized change to the private release workflow, and five seconds later the owner token overrode it. Earlier that week LiteLLM had relaxed its release rule so that any two engineers could trigger and approve a release, to speed up bugfix backports. The attacker had two engineers’ tokens. The legitimate pipeline then built, signed and published the poisoned artifacts.
Cleanup: a third maintainer’s token deleted the workflow run records, and the attacker force-pushed the release repo back to its prior state.

The postmortem also points out something every GitHub organization should know: CLI OAuth tokens are “post-2fa and not subject to GitHub’s ‘super-user’ 2fa reauth flows” for sensitive organization actions. A stolen gh token can therefore do things a human with the same account would be challenged on.

Why this matters beyond LiteLLM

This is LiteLLM’s second supply-chain incident this year, after one in March. The lessons apply well beyond this one project.

Provenance is not the same as trust. The artifacts were signed and built by the real pipeline. Trusted publishing and attestations prove which workflow built a package. They do not prove the workflow definition wasn’t hijacked.
Force-pushing doesn’t un-leak a secret. Public commits get scraped within minutes. The only fix is revocation, and here one key out of a batch slipped through.
Approval gates are only as strong as the tokens that can satisfy them. “Two engineers” means two credentials, and both were long-lived personal OAuth tokens.
AI infrastructure concentrates secrets. A gateway holds keys to every model provider, and agent platforms hand out GitHub tokens so agents can open PRs. The more agents get real credentials, the more an alpha service with a forgotten master key becomes a skeleton key. The stealer’s explicit targeting of AI coding-assistant config shows attackers already know this.

What to do if you might be affected

LiteLLM and StepSecurity agree on the essentials. Don’t start with pip uninstall, because every Python start re-runs the payload. Kill whatever holds /tmp/remote_code_loader.lock, delete cook.pth, cook.py and sitecustomize.py, rebuild environments and images from scratch on 1.106.2 (pin images by digest), and block litellm.dev. If 1.107.0 ran on a host with outbound internet, assume exfiltration succeeded and rotate everything that host could reach. On proxy hosts that includes every provider key in the proxy database, the master and salt keys, and the database password.

Open questions

LiteLLM has not given a count of affected installs, and says the list of process changes is coming “next week”. It has not yet said whether the relaxed two-engineer release rule has been reversed, or how it will scope the tokens its agent platform hands out. Until it does, the honest summary is this: a well-known project had a sound-looking release process, and one unrevoked key from May was enough to get around all of it.