Anyone who installed LiteLLM version 1.107.0 on 21 October, or ran its Docker image that morning, should treat the machine as breached and replace every secret it could reach. LiteLLM is an open-source library that lets one application talk to many AI providers through a single interface, which means its servers often hold the keys to all of them.
The LiteLLM team laid out the incident in a post titled “Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised.” Attackers got into the company’s release pipeline in the early morning and published a build that carried compiled malicious code. It steals credentials and installs tools that let the attacker run commands remotely. Every earlier version is safe, according to the team, and the bad releases have been pulled.
The exposure windows are narrow but not tiny. The poisoned package sat on PyPI, the main Python package index, starting at 11
UTC and ending at 13 UTC, roughly two hours. Four Docker tags (main-stable, main-latest, latest, and v1.107.0) pointed at the poisoned image on Docker Hub from 11 UTC until 14 UTC. The same tags on GitHub’s container registry served it until they went dark by 13 UTC. Teams that pin an exact version were spared. Teams that pull “latest” on a schedule were not.LiteLLM says the tagged source for 1.107.0 on GitHub never held the malicious files. The bad builds came from a repository the attacker controlled, named almost like the real one: Berri-AI rather than BerriAI. Customers on the private enterprise release were not affected.
The company describes a chain of failures rather than a single mistake. After an earlier incident in March, it had shifted releases into a private repository, made Docker tags immutable, and begun signing images. On Monday it temporarily widened release permissions so two engineers could ship daily bugfix backports. The attacker held GitHub command-line credentials for three developers. One belonged to a GitHub organization owner, and the attacker used it to switch off branch protections and force through a change that let the release job build from the lookalike repository.
Where the credentials came from is the part other builders should read twice. LiteLLM says Claude Code, in specific situations, puts the GitHub CLI login token of a user into a response body, and where those bodies are logged, the tokens can land in LiteLLM’s logs. The team found an unfamiliar, innocuously named account on its own internal LiteLLM deployment, which faced the public internet, and believes the attacker pulled the tokens from there. How the attacker got in is unconfirmed. The team suspects a recently patched vulnerability.
What to do, per LiteLLM:
- Check exposure with pip show litellm, and search the disk for sitecustomize.py, cook.pth, or a dist-info folder for the 1.107.0 install. A hit confirms exposure; a miss proves nothing.
- For Docker, the bad image digest begins sha256. A container that ran it is compromised.
- Do not begin with pip install, because running Python at all in that environment, pip included, fires the malicious files again. First remove sitecustomize.py, cook.py, and cook.pth, plus their cached .pyc copies, from each site-packages folder, and kill the background Python process that holds the lock file /tmp/remote_code_loader.lock.
- Go back to litellm==1.106.2, or better, rebuild images and virtual environments from scratch.
- If 1.107.0 ever ran on a machine that could reach the internet, assume the theft succeeded. Rotate the cloud instance role, each provider key kept in the proxy database, the DATABASE_URL password, the master key, the virtual keys, and every secret visible to any process running there.
- Look in CloudTrail for GetCallerIdentity calls by the instance role near install time, then for that role’s credentials turning up outside your infrastructure.
The investigation is still open, and LiteLLM promised updates every two hours.
The lesson reaches past LiteLLM: a gateway that holds every model key is a single prize, so any team running one should audit who can publish to it and where its logs are kept.
Reported by LiteLLM on 21 October 2026.
