Skip to content
audiotale.net
Sign in
NewsNews

LiteLLM 1.107.0 poisoned: PyPI and Docker images stole credentials, how to check and fix

Release 1.107.0 of the AI gateway LiteLLM carried a credential stealer for about 1 hour 44 minutes on 21 October; LiteLLM's analysis traces it to a master key leaked in May.

audiotale.net team

· 7 min read

Written by AI from the sources linked below. How we use AI

On this page
  1. Key points
  2. What to do
  3. What happened
  4. Background
  5. How it worked: the attack chain
  6. The numbers
  7. What it means
  8. What we don't know yet
  9. What to watch next
  10. Sources

LiteLLM 1.107.0, a poisoned release of the popular open-source AI gateway, was live on PyPI for about an hour and 44 minutes on 21 October 2026 and carried a credential stealer plus a remote-access tool. Five days later, LiteLLM's own root-cause analysis shows how it happened: a master key committed to a public repository in May was never revoked, and it led the attacker to GitHub tokens with owner-level access. Anyone who installed or ran 1.107.0, or pulled the latest Docker image that day, should treat every secret that host could reach as stolen.

Key points

  • Only litellm==1.107.0 (seven wheels on PyPI) and the Docker tags v1.107.0, latest, main-latest and main-stable were malicious; the last safe version is 1.106.2 (LiteLLM, Wiz).
  • The PyPI upload came at 11:39 UTC on 21 October and PyPI removed it at about 13:23 UTC; Wiz counts about 49,000 downloads in that window, from ClickPy data.
  • The malicious files are cook.pth, cook.py and sitecustomize.py in site-packages, which run every time Python starts.
  • LiteLLM's analysis traces the break-in to a master key committed to the public LiteLLM-Labs/lite-harness repository on 27 May and never revoked.
  • If 1.107.0 ran on a host with outbound internet, assume exfiltration and rotate cloud, provider, database, SSH and GitHub secrets.

What to do

Who is affected. Anyone who installed litellm==1.107.0 from PyPI, or ran a container from the tags v1.107.0, latest, main-latest or main-stable pulled from Docker Hub or GHCR on 21 October. LiteLLM says the official GitHub source tag did not contain the malicious files, because the artifacts were built from an attacker-controlled repository, and that its enterprise private registry was not affected.

Fix. Pin litellm==1.106.2 or an earlier explicit version. LiteLLM's incident post gives the order that matters:

  1. Do not run pip first in an affected environment, because Python startup re-executes the malicious files.
  2. Remove cook.pth, cook.py, sitecustomize.py and any matching .pyc files from every affected site-packages.
  3. Kill the detached Python daemon holding /tmp/remote_code_loader.lock.
  4. Rebuild images and virtual environments from scratch if you can.

Rotate. LiteLLM lists the instance or task IAM role, all provider keys stored in the LiteLLM proxy database, master and virtual keys, the DATABASE_URL password, and any secret in the environment of host processes. Audit CloudTrail for GetCallerIdentity calls from the instance role around install time and for use of its credentials from outside your infrastructure.

How to check. Search for the three files above. Wiz and The Register also list the run-once marker /tmp/.pc_once_*, the lock file /tmp/remote_code_loader.lock, and traffic to www.litellm[.]dev/healthcheck, a lookalike of the real LiteLLM domain. LiteLLM warns that a missing marker file does not prove a host is clean.

What happened

Wiz's timeline, which matches LiteLLM's, starts on the morning of 21 October (all times UTC). Between about 08:56 and 10:46 the attacker pushed ten commits to Berri-AI/litellm, a hyphenated lookalike of the real BerriAI organisation. At 10:08 a privileged credential overrode branch protection on the real repository, and a workflow change pointed the release pipeline at the lookalike fork. The production pipeline began at 11:08, and a second developer's credential satisfied the production approval gate.

At 11:39:51 seven litellm==1.107.0 wheels were published to PyPI. Docker Hub and GHCR images followed at 11:46:56. By 11:53 the attacker was deleting workflow run records with a third maintainer's token. At 12:06 a user, LidorMachluf, opened issue #47826 identifying the compromise. PyPI quarantined the release at about 13:23, GHCR tags were unavailable by roughly 13:51, and every affected Docker Hub tag was removed or repointed to a clean image at 14:20.

The three injected files do different jobs. cook.pth is a Python path file whose line makes the interpreter run cook.py at startup. cook.py is the stealer. sitecustomize.py is the remote-access component: according to The Register's reading of the research, it spawns a daemon that checks the attacker's infrastructure hourly for commands. Wiz adds that on Linux and macOS it consults a GitHub "dead drop" file for a domain from which it could fetch a second-stage script, and that at the time of its analysis the file held nothing beyond test values.

The stealer has 16 modules. They target browser credentials and cookies, AWS credentials and instance metadata, Google Cloud service-account keys, Azure tokens, API keys for AI providers, SSH and GPG keys and shell history, and the stealer also queries LiteLLM's PostgreSQL credentials table for upstream provider keys. Data is encrypted with AES-256-CBC, the key is wrapped with RSA-4096, and it is posted to the lookalike domain.

Wiz also saw the aftermath: between 16:20 and 17:01 UTC the attacker validated AWS role credentials taken from compromised CI runners and Kubernetes nodes, calling sts:GetCallerIdentity and then Bedrock model-listing APIs. Wiz says this is consistent with LLMjacking, the theft of access to paid AI models.

Background

LiteLLM, from BerriAI, is an open-source gateway that gives one interface to OpenAI, Anthropic, Google Gemini and other providers, which is why a LiteLLM host tends to hold many valuable keys at once. The Register puts its download volume at about 23 million a week. It also reports, citing CloudSEK, that an earlier LiteLLM compromise in March potentially exposed more than 2,500 organisations; we did not verify that figure independently.

Poisoned releases of AI tooling are now a pattern. We have covered a stolen-GitHub-token campaign that planted a workflow to dump secrets and an AGENTS.md trick that hijacks coding agents. What sets this case apart is that the attacker did not break PyPI; they took the maintainers' own release process.

How it worked: the attack chain

LiteLLM published its root-cause analysis on 23 October at 21:00 UTC. Its sequence:

  1. 27 May, 18:53. A file named opencode.json containing the LiteLLM Agent Platform master key was committed to the public LiteLLM-Labs/lite-harness repository. The commit was removed quickly, but the key was never revoked.
  2. 10 October, 21:13 to 21:28. The attacker called the Agent Platform API with that key. At 21:27 a response returned an organisation owner's GitHub CLI OAuth token.
  3. 10 October, 22:11 to 22:14. Throwaway branches in BerriAI/litellm and BerriAI/litellm-auto posted secrets to webhook.site, including the tokens of two more maintainers. The runs were then deleted. A second round of exfiltration from private repositories followed on 12 October.
  4. 21 October. The release hijack described above, then a cleanup: between 12:09 and 12:24 the attacker reverted the workflow change and force-pushed main to hide it.

The GitHub CLI tokens matter because The Register notes they are issued after two-factor authentication, so they do not trigger GitHub's sudo-mode checks for high-impact actions. LiteLLM's own words are that the incident is a "strong illustration of the risks associated with failing to rotate a potentially exposed key".

The numbers

The windows below come from timestamps in LiteLLM's incident post and root-cause analysis; the minute counts are our arithmetic.

How long the malicious 1.107.0 artifacts stayed available (minutes)minutes
How long the malicious 1.107.0 artifacts stayed available (minutes) (minutes)
minutes
Docker Hub tags153
GHCR tags124
PyPI103

Source: LiteLLM incident post and root-cause analysis (timestamps); durations computed by audiotale.net

PyPI: 11:39:51 to about 13:23. GHCR: 11:46:56 to about 13:51. Docker Hub: 11:46:56 to 14:20. The Docker windows are why container users are in more danger than the PyPI figure suggests: an image pulled at 14:00 on latest could still have been malicious.

What it means

For anyone running an AI gateway. These hosts concentrate secrets by design. Run them with narrowly scoped, short-lived credentials, keep provider keys out of environment variables where you can, and set spend limits at the provider so a stolen key cannot run up a bill.

For maintainers. The chain began with a leaked key that sat live for more than four months. Deleting a secret from a repository does not unleak it; rotation is the only fix. The chain also relied on release approvals that one stolen token could satisfy: separate approvers, protected environments and trusted publishing with provenance make this harder.

For consumers of packages. Brand-new releases carry risk. Pinning versions and waiting a day or two before adopting a new release would have avoided this one, because the package was live for under two hours.

What we don't know yet

  • How the attacker first got in. LiteLLM's early posts suspected tokens leaked from internal logs. The root-cause analysis says request logs show the first token came from a different service, and it names the leaked master key. The incident post separately says an exposed internal deployment, possibly via a recently patched vulnerability, is a suspected route and is unconfirmed.
  • The scale of theft. Wiz found a second stage had not been populated at the time of analysis, but nobody has published a count of hosts that actually ran the stealer.
  • Timing details. LiteLLM's acknowledgements say the release was caught within 20 minutes, but its own timeline puts the first public issue about 27 minutes after the PyPI upload. PyPI's quarantine is given as about 13:23 by LiteLLM and 13:20 by Wiz.
  • Who is behind it. None of the sources we read names the attacker. BerriAI did not respond to The Register's inquiries.

What to watch next

LiteLLM says its process improvements will be published "next week" and that it is revoking every token tied to its internal systems and vendor platforms. Watch for Wiz's advisory wiz-adv-2026-188, which carries the full indicator list, and for any report of provider-key abuse tied to the 11:39 to 13:23 window.

Sources

SaveStart the discussion

Written by

audiotale.net team

The official account of the people who run audiotale.net: announcements, conversation starters and the newsroom's drafts. Posts written with AI say so. Every other account here is a real person.

Read next