Category: Security | Reading time: 4 min
On October 21, attackers took over LiteLLM's release process and published a malicious version, 1.107.0, to PyPI and Docker. LiteLLM is the open-source gateway many companies place between their applications and model providers such as OpenAI, Anthropic and Google. It is downloaded about 23 million times a week, and it usually runs next to the API keys for every provider it routes to.
The exposure window
According to LiteLLM's incident notice, the poisoned package was live on PyPI from 11:39 to 13:23 UTC, about two hours. The Docker images were compromised from 11:46 to 14:20 UTC, and the affected tags included `v1.107.0`, `latest`, `main-latest` and `main-stable`. LiteLLM says the incident is contained, that enterprise customers on private releases were not affected, and that 1.106.2 is the last safe version.
Wiz reported that the payload arrived through malicious commits from a lookalike GitHub organization, "Berri-AI", imitating the real "BerriAI".
What the malware did
The package dropped three pieces:
- `cook.pth`, which runs `cook.py` every time Python starts. - `cook.py`, an infostealer with 16 modules covering browser passwords and cookies, AWS credentials (including `~/.aws` and the instance metadata service), Google Cloud keys, Azure CLI tokens, OpenAI, Anthropic and Cohere API keys, SSH and GPG keys, and shell history. - `sitecustomize.py`, a remote access backdoor that checks in hourly for new commands.
Stolen data was encrypted and sent to `litellm[.]dev/healthcheck`. Published indicators include `/tmp/.pc_once_*` and `/tmp/remote_code_loader.lock`. Aikido, Wiz and Socket have published response guidance.
A repeat target
This is not LiteLLM's first compromise this year. CloudSEK estimated that a March 2026 incident potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines, as reported by The Register. The scale of the October incident is not yet known.
Why it matters for agent deployments
Model gateways sit on the path every agent call takes, and they hold the credentials agents use to act. When that layer is compromised, the questions that follow are concrete: which hosts pulled the bad version, which keys were present, and what those keys were used for during and after the window. Teams that can show a verifiable record of what their agents and credentials actually did can answer those questions for auditors and customers. Teams that rely on the gateway's own logs are asking the compromised component to vouch for itself.
Teams that installed or pulled 1.107.0, or any of the affected Docker tags, during the window should treat the host as compromised, rotate every credential it could reach, and pin to 1.106.2.
Source: LiteLLM security incident notice | The Register