A malicious build of LiteLLM 1.107.0, an open-source AI gateway widely used by American developers, reached PyPI and Docker on Wednesday, October 21, carrying a credential stealer and a remote-code loader. The packages came down within hours, but the LiteLLM 1.107.0 malware could have collected cloud keys, browser data and AI provider credentials from any machine that installed it. Because LiteLLM often sits beside those secrets, the exposure reaches well beyond the people who imported the library.

LiteLLM's maintainers said their release pipeline was compromised in the early morning of October 21 and that the bad build pushed v1.107.0 to Docker and PyPI. The project's incident report describes the artifact as "compiled malware which steals credentials and loads remote-code execution tools." The timeline below draws on that report and on third-party analysis from Wiz, StepSecurity, Socket and others.

Which LiteLLM 1.107.0 builds and Docker tags are affected

  • PyPI: All seven litellm 1.107.0 wheels were live from 11:39:51 to 13:23 UTC on October 21, according to LiteLLM's timeline [1][9]. Wiz logged the upload at 11:39 UTC and said PyPI had quarantined the version by 13:20 UTC [3].
  • Docker: The tags v1.107.0, latest, main-latest and main-stable on GHCR and Docker Hub carried the malicious image, which was live from roughly 11:46 to 14:20 UTC [1][4][9].
  • Source tag: The official v1.107.0 tag on GitHub does not contain the malicious files. Wiz and StepSecurity traced the artifacts to an attacker-controlled repository named Berri-AI/litellm, a lookalike of the real project [1][2][3].

The clean source tag matters. Anyone who checks GitHub and sees nothing wrong has not verified what landed on their machine, so audits should examine installed packages and images rather than the repository.

Detection was fast. Socket flagged the wheels seven minutes after publication [6], and Chainguard's malware scanning flagged the release 16 minutes after the first wheel went up, keeping its customers from pulling it [4]. Those minutes still matter. Unpinned installs in CI can grab a new release within seconds, so a window of a few hours gives automated systems plenty of time to pick up the bad build.

LiteLLM says customers on its private enterprise release were not affected [1]. That points to the public PyPI and Docker channels as the exposed path.

What the payload does once Python starts

Each wheel installed three files into site-packages: cook.pth, cook.py and sitecustomize.py [2][4][8]. The .pth file is the dangerous part. Python processes these files at startup, so the code runs whenever the interpreter does, even in a project that never imports LiteLLM [8].

The first stage is a credential stealer that targets browser, cloud and AI secrets. The second stage is a loader that can fetch and run remotely supplied Python. StepSecurity's headline calls it an hourly remote code loader [2], and Cycode and Socket both describe the same two-stage design [5][6].

Stolen data went to a lookalike domain, litellm.dev, which StepSecurity names as the exfiltration point and which was built to blend in with legitimate LiteLLM traffic [2][8]. Wiz also describes a dormant command-and-control capability, so it is unclear whether the attacker used it beyond exfiltration [3].

Why the proxy database raises the stakes

Cycode's analysis contains the most concrete warning in the reporting. The malware queried the LiteLLM Proxy's Postgres table and pulled up to 500 upstream provider keys [5]. A proxy exists to hold credentials for every model provider it routes to, so one compromised host can expose an entire fleet of keys at once.

That changes the cleanup. A developer laptop with one stolen key is a contained problem. A shared proxy with hundreds of keys means finance, security and product teams may all need to rotate credentials. Stolen provider keys can run up usage charges and open access to data sent through the API, which is why the rotation list in this story is long.

The incident also highlights a broader pattern. A single compromised release reaches every project that installs it without pinning, so supply-chain attacks scale in ways a single phished laptop does not.

How the attacker reached the release pipeline

BerriAI reportedly said the attacker used stolen GitHub CLI OAuth tokens belonging to three engineers [5]. That is the most specific account so far, but it is not settled. JFrog says its evidence does not prove which CI system, maintainer machine, PyPI account or publishing credential was compromised [7].

Search results also surfaced two earlier headlines, Chainguard's "LiteLLM attacked again" and JFrog's "LiteLLM hijacked again" [4][7]. USA 24 has not verified the details of that earlier incident or whether it connects to this one.

Token theft is a live tactic this week. USA 24 recently reported that GhostAction returned with a larger wave of stolen GitHub accounts, and attackers hijacked AOMEI update servers to push a Windows backdoor. The targets differ, but the lesson is the same: maintainer accounts and update channels are now the easiest way into the software supply chain.

Which version to downgrade to and how to pin it

The sources disagree on the last clean release. Cycode recommends 1.106.2 [5], while OX Security lists 1.106.0 as the fixed version [8]. Both sit before the bad build, but the difference matters when a team is pinning a version under pressure. Confirm the safe version against LiteLLM's own advisory before changing anything.

Once the advisory confirms a version, pin it explicitly, for example with pip install "litellm==", instead of running an unpinned upgrade. Verify that the installed version matches the pin, and rebuild any container image that carried 1.107.0.

Checklist to run and keys to rotate today

  1. Run pip show litellm on developer laptops, CI runners and build hosts, and check for version 1.107.0. Run docker image ls to find LiteLLM images pulled on October 21.
  2. Search site-packages for cook.pth, cook.py and sitecustomize.py [4]. Some Python environments legitimately include a sitecustomize.py, so compare its contents rather than deleting it on sight.
  3. Treat any host that installed 1.107.0 as fully compromised, not merely cleaned [1][9]. Deleting the files does not undo credentials that already left the machine.
  4. Rotate LLM provider keys, cloud credentials and any secrets stored in environment variables or the proxy database [1][9].
  5. Revoke and reissue GitHub CLI OAuth tokens, then audit repository access and recent activity [5].
  6. Block or review outbound traffic to litellm.dev [2].
  7. Pin the confirmed safe version and rebuild container images from clean base layers.

What to watch as the investigation continues

No source gives a download or install count, so the number of affected machines is unknown. None of the sources names a US company as a victim. That does not rule out American exposure, since LiteLLM is widely used by US developers and companies.

Watch for three things: LiteLLM's full post-incident report, a single confirmed safe version, and any change to how the project's release pipeline authenticates publishers. Those answers will determine how far the rotation effort has to reach, and whether the earlier LiteLLM compromise belongs to the same story. Teams that installed anything from the project on October 21 should treat today as a rotation day.