A poisoned release of LiteLLM, the open source gateway many teams put between their applications and large language model providers, spent roughly two hours on PyPI and Docker registries on 21 October. Anyone who installed version 1.107.0 or pulled a floating container tag in that window should assume the host’s secrets have been stolen.
What happened
This is a supply chain compromise of one release, separate from the LiteLLM gateway flaws we covered on 16 October. Here the downloaded code was itself malicious, so updating to the newest version was exactly what exposed people.
According to Wiz, the trojanised LiteLLM 1.107.0 landed on PyPI at 11:39 UTC on Wednesday 21 October and was quarantined at 13:20 UTC. Official container images on Docker Hub and GHCR carried the same payload, including under the floating latest, main-latest and main-stable tags, until removal at around 13:53 UTC. The last clean release is 1.106.2.
LiteLLM is maintained by BerriAI and gives developers a single interface to OpenAI, Anthropic, Google Gemini and dozens of other model providers. The Register reports about 23 million weekly downloads. Aikido Security, Wiz and Socket all published analysis and indicators of compromise on the day. Aikido says LiteLLM regards the incident as contained, and the project told Wiz that all tokens involved have been revoked.
The technical picture
The route in is the part every engineering leader should read twice. BerriAI told Wiz that the attacker drove the release workflow through three engineers’ GitHub accounts using stolen GitHub CLI OAuth tokens, with one account triggering the release run and another approving it. Those tokens appear to have leaked through logs held in an internal LiteLLM deployment that was reachable from the internet, where an unexpected account had been created. BerriAI said Claude Code can, in some circumstances, place a user’s GitHub CLI token in a response body, which then ends up in logs if bodies are recorded. How the attacker first got into that deployment is not yet confirmed; the project suspects a recently patched flaw.
The malicious commits were made in a lookalike organisation, Berri-AI/litellm, one hyphen away from the genuine BerriAI. Aikido found the source tree on GitHub was never altered. Instead, a build directive in pyproject.toml told the Rust and Python packaging tool to bundle a cook directory that existed only in the compromised build environment. Socket observed that container provenance records pointed at the hyphenated repository.
Three files were dropped into site-packages. A .pth file causes a heavily obfuscated stealer to run whenever any Python interpreter starts, even if LiteLLM is never imported. A sitecustomize.py file starts a background daemon on Linux and macOS that checks hourly for new Python to execute. Wiz believes pairing both startup tricks is a first in the wild, and says the code shows signs of having been written with LLM help.
The stealer is broad: browser passwords and cookies, SSH and GPG keys, cloud credentials for AWS, Azure and Google Cloud (including instance metadata), Kubernetes and CI/CD secrets, and configuration for AI coding tools such as Claude Code, Cursor and GitHub Copilot. Crucially for a gateway, it also queries LiteLLM’s own database and lifts the stored provider keys. Results are encrypted and posted to a domain impersonating the project.
Wiz then watched the stolen material being used. About four and a half hours after exfiltration, the attacker began checking AWS role credentials taken from CI runners and Kubernetes nodes, then listing available Bedrock models: classic LLMjacking, where criminals run up model usage on a victim’s bill. In some environments IAM users, roles and access keys were also enumerated.
Why it matters for UK organisations
LiteLLM turns up wherever UK teams have moved quickly on generative AI: internal assistants, retrieval systems, agent platforms and evaluation pipelines. It typically runs in a container with a cloud role attached and a database of provider keys, which makes a poisoned gateway worth far more to an attacker than an ordinary library.
The exposure is also wider than “did we install 1.107.0”. Any image built or job run during the window that pulled latest could be affected, as could developer laptops, because the stealer goes after browser sessions and AI coding assistant tokens. Socket warns that running Python or pip on an infected host to investigate can trigger the payload again.
If personal data was reachable with stolen credentials, a reportable breach to the Information Commission (which took over the ICO’s functions on 30 September) may follow, and the usual 72-hour clock applies once you are aware of it. Managed service providers that host AI platforms for clients should note that this is the kind of supplier incident the Cyber Security and Resilience Bill is designed to bring into scope.
Expert view
When we test AI deployments, the gateway is consistently the soft centre: a single service holding every model key, a cloud role with more permission than it needs, and verbose request logging switched on for debugging and never switched off. This incident chains all three. Logged response bodies leaked release credentials, a publicly reachable internal deployment exposed those logs, and the resulting package landed in environments built to hold secrets.
The token angle matters beyond LiteLLM. In my experience, organisations treat CLI OAuth tokens on developer machines as low-risk convenience, yet here they were enough to trigger and approve a release. Two-person approval only works if the two people are actually two people.
Four and a half hours from theft to credential validation is shorter than many organisations take to notice a malicious package. Rotation must be rehearsed.
What to do now
- Find exposure. Search lock files, SBOMs, image registries and CI logs for litellm 1.107.0 and for any LiteLLM image pulled by floating tag on 21 October. Check hosts for the /tmp/.pc_once_ marker and /tmp/remote_code_loader.lock published by Aikido and Wiz.
- Isolate before investigating. Treat affected hosts and runners as compromised. Rebuild rather than clean, and avoid running Python on them while triaging.
- Rotate from a clean machine. Cloud keys and instance roles, every model provider key stored in LiteLLM, SSH and GPG keys, CI/CD and Vault tokens, Git and package registry credentials, and AI coding tool tokens. Revoke browser sessions for affected users.
- Hunt for LLMjacking. Review CloudTrail for GetCallerIdentity followed by Bedrock model listing, unexpected IAM enumeration, and unusual model spend. Block the published network indicators at egress.
- Pin and verify. Pin to 1.106.2 or a later reviewed release by digest, not tag. It is security update management, as Cyber Essentials frames it, applied with care: update deliberately, not automatically.
- Tighten the gateway. Least-privilege cloud roles, no internet exposure for admin interfaces, and logging that redacts response bodies and tokens (Cyber Essentials secure configuration and user access control).
- Review your own release pipeline. Shorten OAuth token lifetimes, require hardware-backed approval for releases, and restrict builds to approved repositories.
Bottom line
The LiteLLM 1.107.0 compromise shows the AI stack inheriting every old supply chain problem, with richer secrets at the end of it. If you ran it, assume compromise and rotate everything. If you did not, use this week to check how you would know, and how quickly you could rotate every key your AI gateway holds.
