LiteLLM 1.107.0 hijacked on PyPI and Docker, shipping a credential stealer

What happened

On 21 October 2026, LiteLLM's release pipeline was used to publish litellm 1.107.0 to PyPI and to its Docker images with compiled malware: a credential stealer and a remote-code loader. LiteLLM says all earlier versions are safe and the affected releases have been pulled.

The official v1.107.0 source tag on GitHub does not contain the malicious files. The artifacts were built from a lookalike repository, Berri-AI/litellm, which differs from the real BerriAI/litellm by one hyphen. All seven wheels add cook.pth, cook.py and sitecustomize.py to site-packages, so the malware runs whenever Python starts, even if litellm is never imported.

The stealer collects credentials, environment variables and cloud metadata, encrypts them and sends them to litellm.dev. The loader polls a GitHub file hourly for a domain and runs code from it, but the file was empty, so that stage was dormant and no second stage was observed. Wiz reports that the attacker validated stolen AWS instance role credentials, and SecurityWeek says Wiz saw stolen AWS credentials used to query Amazon Bedrock models about 4.5 hours after exfiltration, suggesting LLMjacking.

LiteLLM says the attacker used a GitHub CLI OAuth token, obtained through an internal LiteLLM deployment exposed to the internet, to compromise the release workflow. Other sources say tokens from three engineers' accounts were used. SecurityWeek reports the tokens were likely leaked by Claude Code placing them in response bodies that may have been logged. LiteLLM says investigators have not confirmed how the attacker entered the internal deployment, and the investigation is ongoing.

PyPI removed 1.107.0 by 13:23 UTC on 21 October. Affected GHCR tags were unavailable by 13:51 UTC, and by 14:20 UTC all affected Docker Hub tags had been removed or repointed to verified clean artifacts. According to Aikido, GitHub took down the attacker's dead-drop repository.

Background

Processes running LiteLLM typically hold provider API keys, cloud identities and database connection strings, which makes them an attractive target for credential theft. Datadog notes an earlier 2026 LiteLLM incident affected versions 1.82.7 and 1.82.8, and that no connection between the two has been established.

StepSecurity says that because the malicious artifacts were built and published by the legitimate pipeline with valid provenance, the hardening measures introduced in March did not prevent this compromise.

How it works

Per Socket, Endor Labs and Aikido, a maturin data setting added to pyproject.toml (data = "cook") bundled a directory absent from the tagged source into the wheels, and a COPY line in the Dockerfiles did the same for images. The tag's pyproject.toml lacks the setting, so reviewing the tag alone would miss it. The sdist contains the setting but not the cook directory, so it has no payload.

According to the project's account, an attacker-used credential overrode branch protection to modify the private release workflow, pointing it at Berri-AI/litellm. The workflow ran staging, then production, with a second developer credential satisfying the approval gate. A third developer's credentials were then used to delete workflow records, limiting available logs. Build provenance recorded the lookalike repository as the source.

At runtime, cook.pth launches cook.py on every interpreter start. The stealer gathers host information, browser passwords, SSH keys, cloud and developer credentials, AI tool configs, environment variables and, when DATABASE_URL is set, LiteLLM proxy provider keys. The stealer protects what it collects with AES-256-CBC encryption, locks the key using RSA-4096 OAEP-SHA256, and sends the package over unencrypted HTTP to litellm.dev. The marker file is only written after a successful HTTP 200, so the stealer reruns on each Python start while exfiltration fails.

sitecustomize.py starts a background daemon that checks a GitHub file hourly for a domain, then fetches /codepy from it and executes the response with no signature or hash check. Deleting the litellm folder does not remove the dropped files; running python or pip triggers the malware again.

Timeline

1. 13 Oct 2026
   00:45 UTC

   The litellm.dev domain was registered.[2]

2. 21 Oct 2026
   08:56 UTC

   First attacker commit to Berri-AI/litellm, adding cook.pth.[2]

3. 21 Oct 2026, 10:08 UTC

   A privileged developer credential overrode branch protection and applied a workflow commit.[1]

4. 21 Oct 2026, 10:46 UTC

   The modified workflow started a staging run from Berri-AI/litellm.[1]

5. 21 Oct 2026, 11:39 UTC

   Seven malicious litellm 1.107.0 wheels were uploaded to PyPI.[1]

6. 21 Oct 2026, 11:46 UTC

   Container publication jobs ran and the Docker image included malicious content.[1]

7. 21 Oct 2026, 12:09 UTC

   The unauthorized workflow revision was removed and the release workflow restored.[1]

8. 21 Oct 2026, 13:23 UTC

   PyPI had removed litellm 1.107.0.[1]

9. 21 Oct 2026, 13:51 UTC

   Affected GHCR tags were unavailable; Docker Hub tags still resolved to the compromised image.[1]

10. 21 Oct 2026, 14:20 UTC

    All affected Docker Hub tags were removed or repointed to clean artifacts.[1]

Who is affected

• Anyone who installed litellm 1.107.0 from PyPI, including unpinned installs and open-ended constraints that resolved to it. Any Python process in that environment runs the malware.
• Anyone who ran the Docker images tagged v1.107.0, latest, main-latest or main-stable in the window, on GHCR or Docker Hub.
• LiteLLM proxy hosts with DATABASE_URL set should assume stored provider credentials were taken.
• Not affected, per LiteLLM: enterprise customers on the private registry, and earlier versions.

Impact

Wiz cites about 49,000 downloads of the malicious version per ClickPy, and SecurityWeek says the packages were online for roughly three hours. Datadog puts availability at about two hours. Socket's scanner flagged the seven wheels seven minutes after publication.

The PyPI exposure window runs from about 11:39 to 13:23 UTC and the Docker window from about 11:46 to 14:20 UTC. Unpinned installs and deployments following floating tags such as latest or main-stable could receive the bad release without choosing it. Enterprise customers using the private registry were not affected, according to LiteLLM.

How to check

1. Run pip show litellm, and search lockfiles, requirements, caches, CI build logs and container layers for litellm 1.107.0.
2. Search site-packages for cook.pth, cook.py, sitecustomize.py and litellm-1.107.0.dist-info. Finding one confirms exposure; finding none does not prove the environment is clean. Prefer checking on disk without running Python.
3. Check /tmp for the marker file /tmp/.pc_once_72129118c59f5636c0bb and for /tmp/remote_code_loader.lock. Absence of the marker proves nothing.
4. Check which image digests your deployments or Kubernetes pods ran on 21 October.
5. Search egress logs for litellm.dev, including POSTs to /healthcheck and requests ending in /codepy, and check CloudTrail for GetCallerIdentity from the instance role around install time.

What to do

1. Do not start pip first in an affected environment; each Python start reruns the payload. Isolate affected hosts and preserve evidence.
2. Kill the detached Python daemon holding /tmp/remote_code_loader.lock.
3. Delete cook.pth, cook.py, sitecustomize.py and matching pycache files from affected site-packages.
4. Rebuild environments and images from scratch and pin litellm==1.106.2, or the v1.106.2 image by digest.
5. Assume exfiltration succeeded and, from a clean machine, rotate everything the host could reach: IAM roles, provider keys, master and virtual keys, the DATABASE_URL password and environment secrets.
6. Block litellm.dev at DNS or egress and block litellm==1.107.0 in your package proxy.