- LiteLLM says its release pipeline was compromised on October 21 and pushed a credential-stealing version, 1.107.0, to PyPI and Docker. It suspects GitHub tokens in its own logs.
- LiteLLM says an attacker with three sets of developer credentials overrode branch protection, passed an approval gate and deleted workflow records. The investigation is ongoing.
- Teams that ran unpinned LiteLLM in the affected windows should treat those hosts as compromised, rebuild them and rotate every secret they could reach.
An AI gateway sits between a company's people and its AI models. That position makes it useful. It also means the gateway's logs can collect things nobody meant to keep, including keys to other systems. LiteLLM's account of the October 21 incident points to how that can go wrong.
What LiteLLM says happened
LiteLLM is an open-source AI gateway. It says its release pipeline was compromised early on October 21. The pipeline pushed version 1.107.0 to PyPI, the Python package index, and to Docker registries. LiteLLM says that version held compiled malware. The malware steals credentials and loads tools for running remote code.
The PyPI package was live from 11:39 to 13:23 UTC. Docker tags including v1.107.0 and latest pointed to a bad image from 11:46 to 14:20 UTC. LiteLLM says all earlier versions are safe. It says enterprise customers on its private registry were not affected.
One detail matters to anyone who reviews code. LiteLLM says the official v1.107.0 source tag on GitHub was clean. The bad files came from a different repository the attacker controlled. Its name differed from the real BerriAI/litellm by a single hyphen: Berri-AI/litellm. A code review of the official repository would have found nothing.
The suspected way in: secrets sitting in logs
LiteLLM says Claude Code sometimes places a user's GitHub CLI OAuth token inside a response body. If a gateway logs response bodies, the token lands in the log.
LiteLLM also found an unexpected user account on an internal LiteLLM deployment that faced the public internet. It believes the attacker took GitHub tokens from that deployment's logs. It believes the attacker then used them against the release workflow.
These are beliefs, not findings. LiteLLM has not confirmed how the attacker got into the deployment. It suspects a recently patched vulnerability but has not named one.
This points to a place secrets can end up that nobody planned for. In a gateway, a token can land in a log as a side effect of ordinary traffic. Nobody chose to store it, so nobody guards it like a vault.
Three tokens, two controls and a cleanup
After an earlier incident in March, LiteLLM says it hardened its pipeline. Releases moved to a private repository. Docker tags became immutable. Images were signed. Publishing was limited to an account tied to one laptop in its office.
LiteLLM says the attacker held three sets of developer GitHub credentials. At 10:08:29 UTC, branch protection blocked an unauthorized change to the release workflow. Five seconds later, a privileged developer credential overrode that protection. LiteLLM says one token belonged to one of its two GitHub organization owners.
At 11:11, a second developer's credential satisfied the production approval gate. At 11:53, a third developer's credentials deleted the workflow records. That limited the logs available to investigators. LiteLLM also says it had widened release permissions on Monday so two engineers could publish bugfix backports.
The lesson is that each control was built for an attacker holding one stolen identity. Here the attacker held several. The workflow also signed and published the poisoned files. So a signature showed who ran the build. It did not show the contents were sound.
How the malware works
The Hacker News reported the technical detail from researchers at Aikido and Wiz. Python reads small startup files with the .pth ending. The package carried one, cook.pth. It loads a script, cook.py, which unpacks itself.
The Hacker News reports the script runs a stealer called privcollect. The stealer reaches into the machine, browsers, developer tools, cloud accounts and AI tools. It uploads what it finds to an address on litellm[.]dev.
A second file, sitecustomize.py, runs only on Linux and macOS. It checks a GitHub page for a server address. It then downloads and runs more code from that server. Aikido researcher Ilyas Makari says a background process repeats this every hour. That gives the attacker a lasting way back in.
Wiz researchers Benjamin Read and Rami McCarthy say using both startup tricks together "appears to be the first documented case in the wild." LiteLLM warns that any Python start in an affected environment reruns both files. That includes running pip.
What happened to the stolen keys
Wiz saw stolen cloud credentials being abused about four and a half hours after they left victim machines. The attacker was checking AWS instance role credentials that came from infected CI runners and Kubernetes nodes. Wiz saw those checks arrive from separate IP addresses. Each credential was tested with a call named sts:GetCallerIdentity. Then came calls listing AI models on Amazon Bedrock.
Wiz called this consistent with LLMjacking. That means using stolen cloud access to run AI models on someone else's bill. In a small number of environments, Wiz saw the attacker list IAM roles, users and access keys.
What to ask your team
First, did anyone run unpinned LiteLLM through pip, or pull the affected Docker tags, during those windows? LiteLLM says to treat those environments as compromised. It advises pinning to 1.106.2 and rebuilding images and virtual environments from scratch. It also says to rotate every secret the host could reach. That includes cloud roles, provider keys in the proxy database and anything in process environments.
LiteLLM adds that finding no marker file proves nothing. Containers and cleanup remove it. Ask for a CloudTrail check of GetCallerIdentity calls from instance roles. Then ask whether those roles were used from outside your infrastructure.
Second, ask about your own gateways. Do they log response bodies? Who can read those logs? Do the logs hold tokens? Can the public internet reach the gateway? Are temporary permission increases recorded and reversed?
LiteLLM says it will keep updating its post, so details may change. For now, one point stands. A control is only as sound as the keys to it. In this case, the keys appear to have ended up in logs nobody was guarding.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: LiteLLM (BerriAI).
