LiteLLM 1.107.0 compromised: infostealer and RAT on PyPI, Docker

On 21 October 2026 the release pipeline of LiteLLM, BerriAI’s open source gateway that offers a single interface to OpenAI, Anthropic, Google Gemini and other model providers, published a malicious version: 1.107.0, on PyPI, Docker Hub and GHCR. It contained an infostealer targeting cloud, development and AI service credentials, plus a remote access trojan (RAT). It is the project’s second supply chain attack this year, after the March incident linked to the Trivy scanner used in its CI/CD.

What happened

According to LiteLLM’s report, the attacker used the GitHub CLI OAuth tokens of three developers: one account modified the pipeline and triggered the release, a second approved it, a third deleted the workflow records. According to SecurityWeek, the attacker also disabled branch protections and pointed the release at the repository Berri-AI/litellm, one hyphen away from the legitimate BerriAI/litellm. The workflow then signed and published the poisoned artifacts: the signed images introduced after March were not enough.

The company believes the tokens were taken from the logs of one of its internal LiteLLM deployments exposed to the internet, where an unexpected, innocuously named user account appeared. It has observed specific cases in which Claude Code embeds the GitHub CLI token in a response body: if response bodies are logged, the token ends up in the logs. How the attacker got in is not confirmed; LiteLLM suspects a recently patched vulnerability. A The Hacker News article dated 24 October points in its headline to a leaked LiteLLM master key: we were unable to read its text.

Exposure windows from the report, as quoted by BleepingComputer:

• PyPI: litellm==1.107.0, all seven wheels for Windows, Linux and macOS, from 11:39 to 13:23 UTC;
• Docker Hub: tags v1.107.0, latest, main-latest and main-stable from 11:46 to 14:20 UTC, pointing to the index sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e;
• GHCR: the same tags until 13:51 UTC, including the litellm-database and litellm-non_root variants.

SecurityWeek, the only source to do so, estimates more than 49,000 downloads. The latest clean version is 1.106.2; customers of the private enterprise registry are not affected.

Technical details

The application code was not touched: the package added three files at the root of site-packages.

• cook.pth: executable lines in .pth files are processed every time the interpreter starts, and this one launches cook.py, the infostealer;
• sitecustomize.py: also imported at startup, it launches a separate loader that every hour reads a pointer hosted on GitHub (a dead drop), then downloads and runs Python code.

The malware therefore runs every time Python starts in the environment, even if the application does not use LiteLLM, and even when you run python or pip to investigate.

According to Wiz the infostealer has 16 modules. It collects AWS credentials (~/.aws/, environment variables, EC2/ECS metadata), Google Cloud, Azure, Kubernetes and Docker credentials; Git, GitHub, npm, PyPI and CI/CD secrets, .env files, SSH and GPG keys, shell history; API keys for OpenAI, Anthropic and other providers, authentication files for Codex, Claude, Gemini and Cursor; browser passwords, cookies and history. It also looks for provider credentials stored in the LiteLLM proxy database: researchers say this shows intent, not proven success. The data, encrypted with AES-256-CBC with the key protected by RSA-4096, is sent via HTTP POST to www.litellm[.]dev/healthcheck.

Public indicators: according to Aikido, /tmp/.pc_once_* (exfiltration has happened) and /tmp/remote_code_loader.lock (the loader has run or is active); then the domain litellm[.]dev, the repository Berri-AI/litellm and the image digest given earlier.

Use of the credentials: Wiz saw the attacker, about four and a half hours after exfiltration, validating AWS keys taken from CI runners and Kubernetes nodes and testing access to Amazon Bedrock models (LLMjacking); in a few environments the attacker then listed IAM roles, users and access keys.

In our reading the relevant MITRE ATT&CK techniques are T1195.002 (Compromise Software Supply Chain), T1546.018 (Python Startup Hooks), T1552 (Unsecured Credentials) and T1102.001 (Dead Drop Resolver).

Impact on European and Italian companies

An AI gateway concentrates the keys of several providers and often runs with cloud identities and database access: the damage can go well beyond API keys. Developer workstations and CI runners that installed the library as a dependency are exposed too. Two general lessons: a valid signature says the artifact has not changed since signing, not that it was safe; and an AI gateway’s logs can capture secrets.

For NIS2 entities, supply chain security is a mandatory measure: running 1.107.0 on systems with access to infrastructure should be assessed as a possibly reportable incident, depending on the access obtained. If the proxy database held logs containing personal data, the GDPR notification should be considered as well.

What to do now

1. Identify environments, workstations and runners with 1.107.0, and images pulled during the window with the latest, main-latest or main-stable tags: lockfiles, package registries, digests.
2. Do not start Python or pip on suspect systems: look from outside for cook.pth, cook.py, sitecustomize.py and the files in /tmp, and search network logs for the litellm[.]dev domain. Missing indicators do not prove the environment is clean.
3. Isolate and rebuild from trusted images, preserving evidence: removing only the package can leave the startup files and the loader active. Pin 1.106.2 by hash or digest, not by tag.
4. Rotate every reachable secret: cloud, AI providers (including those stored in the proxy), Kubernetes, CI/CD, Git and registries, SSH keys; end browser sessions on affected workstations.
5. Look for credential use since 21 October: Bedrock calls, IAM enumeration, new keys, unusual model token consumption.
6. Harden the pipeline: independent approval of changes to release workflows, no response bodies in gateway logs, management interfaces not exposed to the internet.

How ARXDOME helps

ARX Sentry uses its agent to collect the software and process inventory of Windows, Linux and macOS computers and servers, and checks file integrity in the chosen folders: it helps you find the machines running LiteLLM and spot new files where they should not be. If a machine is suspect, ARX Shield lets you isolate it from the network until it is rebuilt.

Last updated: 24 October 2026