LiteLLM 1.107.0 shipped a credential stealer and RAT

Version 1.107.0 of LiteLLM, the open-source proxy that routes requests across dozens of LLM providers, shipped on October 21 with a credential stealer and a remote access trojan built into its PyPI wheels and official Docker image. The malicious artifacts were live for under three hours. LiteLLM, which reports roughly 23 million weekly PyPI downloads according to Socket, says anyone who installed the package or started the image in the window should assume their credentials are gone.

Key facts

• The seven malicious litellm==1.107.0 wheels on PyPI were live from 11:39:51 to 13:23 UTC on October 21; the Docker tags v1.107.0, latest, main-latest and main-stable pointed at the compromised image from 11:46 to 14:20 UTC.
• The package carried two payloads: an infostealer that runs at every Python interpreter start, and a remote access trojan that polls an attacker server every hour for new code to execute.
• The stealer reads the LiteLLM proxy database directly, including every row of the LiteLLM_CredentialsTable of stored provider API keys, plus AWS, GCP and Azure credentials, SSH and GPG private keys, and configs for tools like Claude Code and Cursor.
• Wiz reports it observed abuse of stolen credentials starting about 4.5 hours after exfiltration, including AWS sts:GetCallerIdentity calls and listing of Amazon Bedrock models, which Wiz calls consistent with LLMjacking.
• This is the second LiteLLM PyPI compromise in 2026: versions 1.82.7 and 1.82.8 were published with credential-harvesting malware in March.

What happened

LiteLLM's incident report says the release pipeline was compromised early on October 21 and pushed v1.107.0 to PyPI and the Docker registry with "compiled malware which steals credentials and loads remote-code execution tools." The official v1.107.0 source tag on GitHub does not contain the malicious files. The artifacts were built from an attacker-controlled repository, which LiteLLM's timeline identifies as Berri-AI/litellm, one hyphen away from the legitimate BerriAI organization.

The attack chain, as LiteLLM describes it in a 21:22 UTC status update on its incident issue: the attacker obtained GitHub CLI OAuth tokens for three of LiteLLM's engineers. LiteLLM believes the tokens leaked through an internal LiteLLM deployment that was exposed to the public internet, and says its investigation found situations where Claude Code embeds a user's GitHub CLI OAuth token into a response body which can then appear in LiteLLM logs. That last part is LiteLLM's account; Anthropic has not confirmed it. At 10:08 UTC, branch protection rejected an unauthorized change to the private release workflow. Seconds later, a credential tied to an organization owner was used to disable branch protections and force the change through. The modified workflow built the release from the lookalike repository, a second engineer's credential satisfied the production approval gate, and a third account deleted the workflow records to limit the logs available for investigation.

Researchers at Aikido, Wiz and StepSecurity document what landed in site-packages: three files, cook.pth, cook.py and sitecustomize.py, that Python executes at every interpreter start, in every environment where the wheel was installed, even if the project never imports LiteLLM. cook.py is a heavily obfuscated infostealer that harvests browser passwords, shell history, cloud credentials including live instance metadata endpoints, Kubernetes service account tokens, CI/CD secrets, and the contents of the LiteLLM proxy database itself. Everything is encrypted with an RSA-4096 key baked into the payload and posted to the lookalike domain litellm[.]dev. sitecustomize.py forks a daemon that checks a GitHub dead-drop repository every hour and runs whatever Python the attacker serves, with the full privileges of the host and no sandboxing.

LiteLLM's response was to pull the package and images, quarantine the release on PyPI, repoint the floating Docker tags to clean artifacts, lock its registries to new releases, and pause ordinary releases. The project is now rotating what it describes as "every authentication token across our organization." LiteLLM says the private enterprise release was not affected. As of October 22 there is no CVE; the incident is tracked as MAL-2026-2144 in the OpenSSF Malicious Packages database.

Why it matters

LiteLLM is the connective tissue of the self-hosted AI stack: it holds the provider API keys for every backend a team uses, in one database, next to the cloud identities those keys can reach. A credential steal here crosses every provider boundary at once. The exposure window was short, under three hours for PyPI and under three for Docker, but the malware was built to outlast it. The RAT keeps checking in hourly, so a machine infected on October 21 can receive new payloads indefinitely until it is rebuilt.

The timing detail from Wiz is the part self-hosters should sit with: stolen AWS credentials were being tested and used to list Bedrock models within about 4.5 hours of exfiltration. Rotation is not a weekend task in this scenario. It is the difference between an incident report and a cloud bill.

This is also the second LiteLLM compromise this year, after 1.82.7 and 1.82.8 shipped credential-harvesting malware in March with different tooling. We covered the earlier pattern of self-hosted AI infrastructure being targeted in our report on the PoeLLM botnet, which compromised more than 3,400 exposed servers running LiteLLM and Ollama. The March incident forced LiteLLM to harden its pipeline with private release repos, trusted publishers, immutable tags and signed images. The attacker went around that hardening by stealing human credentials and using an organization owner's token to turn branch protection off. Controls on the pipeline did not fail; the identity layer did.

Background

LiteLLM is a Python SDK and proxy that sits in front of providers like OpenAI, Anthropic and Google Gemini, normalizing their APIs behind one interface. That position, next to provider keys, cloud credentials and database connection strings, is exactly what makes the package a high-value supply-chain target, and it is the same position covered in our guide to the OpenAI-compatible API layer and in our comparison of self-hosting versus paying per token. Running the gateway yourself keeps prompts off third-party platforms, but it makes you the operator of record for every secret the gateway holds.

The steering of this incident is worth naming precisely. The attacker did not poison the source. Anyone reviewing the v1.107.0 tag on GitHub would have seen clean code, because the malicious artifacts were compiled from the lookalike repository Berri-AI/litellm. The injection point was the build: Aikido found a data directive in pyproject.toml that bundles a directory named cook/ into the wheels, a directory that exists only in the compromised build environment. Source review, one of the standard defenses after a supply-chain incident, would have found nothing.

The disclosure discipline worked as it should. Aikido published its analysis on October 21, OX Security and Rescana corroborated the findings and the exposure windows, and LiteLLM posted rolling status updates on its incident issue roughly every two hours, including the unflattering parts, like the workflow-log deletion and the suspected Claude Code token-leak path. What is still missing: no CVE, no GitHub security advisory for 1.107.0, and no confirmed answer on how the attacker first reached the internal deployment that held the tokens.

What's next

Three things to watch. First, LiteLLM's promised status updates on issue #47826, including its account of how the internal deployment was reached and whether the tokens being rotated show any sign of misuse. Second, a CVE or GitHub security advisory, which would move this from a malware-database entry into the standard vulnerability tooling that pinned-dependency automation actually consumes. Third, whether the incident changes how Python's .pth and sitecustomize.py startup mechanisms are treated in package security scanning, since both major components of this malware relied on running before any user code.

For defenders, the checklist LiteLLM and the researchers agree on is unchanged: isolate affected hosts before cleanup, because even running pip re-executes the payload; rebuild images and virtualenvs from scratch; pin to 1.106.2 or any explicit earlier version; check for cook.pth, sitecustomize.py, /tmp/.pc_once_* and /tmp/remote_code_loader.lock, remembering that their absence proves nothing; rotate every provider key, cloud credential, SSH key and CI token the host could reach, from a clean machine; and review CloudTrail for GetCallerIdentity calls and unfamiliar Bedrock usage around the window.