LiteLLM’s logo. Image: LiteLLM (BerriAI) brand assets
For about an hour and three quarters on Wednesday, anyone who installed the latest version of LiteLLM got a credential stealer with it. BerriAI, the start-up behind the popular open-source tool, confirmed in an incident report that version 1.107.0, published to the Python Package Index (PyPI) and Docker on October 21, “contained compiled malware which steals credentials and loads remote-code execution tools”.
LiteLLM is plumbing that many AI apps quietly depend on. Developers use it to call OpenAI, Anthropic, Google and more than 100 other model providers through one interface, so it often holds a company’s whole set of AI API keys. The security firm Socket puts its downloads at about 23 million a week. It is the second time this year the project has been hijacked.
How the attackers got in
BerriAI says the attacker used three of its engineers’ GitHub accounts, apparently through stolen GitHub CLI login tokens. At 10:08 UTC one account overrode GitHub’s branch protection to change the company’s private release workflow, which then built the release from an attacker-controlled copy of the code (the issue’s reporter traced it to a lookalike organisation, “Berri-AI”). A second account approved the release and a third deleted the workflow records afterwards.
Seven malicious wheels went up on PyPI between 11:39:51 and 11:40:13 UTC. The official v1.107.0 source code on GitHub is clean, so checking it would have shown nothing wrong. BerriAI has not yet worked out how the tokens were stolen.
Scanners caught it fast. AISLE says its dependency firewall flagged the first wheel 3 minutes 14 seconds after upload, and the security firm Upwind opened a public warning on LiteLLM’s GitHub soon after. PyPI had removed the release by 13:23 UTC. The tainted Docker images, including the latest, main-latest and main-stable tags, stayed up on Docker Hub until 14:20.
What the malware steals
The wheels add three files, cook.pth, cook.py and sitecustomize.py, that run every time Python starts on the machine, even in programs that never use LiteLLM. SafeDep’s analysis lists what it takes: SSH keys, AWS, Azure and Google Cloud credentials, Kubernetes and Docker secrets, CI/CD and Terraform secrets, browser passwords, shell history, environment variables and the login tokens of AI coding tools including Claude Code, Cursor, Copilot and Codex.
On a LiteLLM proxy it also raids the database tables that hold every connected provider key. JFrog’s Guy Korolevski explained why that matters:
A compromised proxy host can therefore expose credentials for many upstream AI providers at once.
Guy Korolevski, security researcher, JFrog
The haul is encrypted and sent to litellm[.]dev, a lookalike domain that JFrog found was registered on October 13; the real project uses litellm.ai. A second component starts a hidden process that checks a GitHub file every hour for a server address, then downloads and runs code from it. SafeDep says that GitHub account was gone by 13:40 UTC, so the loader is dormant for now, but machines that ran it earlier may already have received a second stage.
What LiteLLM users should do
BerriAI says to pin litellm==1.106.2 or any earlier explicit version and rebuild environments and images from scratch. Its advice is blunt:
If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded.
Nate Armstrong, lead Rust engineer, LiteLLM
Don’t run pip in an affected environment first: any Python start triggers the payload again. Delete the three files and their cached copies, kill the detached Python process holding /tmp/remote_code_loader.lock, then rotate everything the machine could reach: cloud roles, every provider key in the proxy database, LiteLLM master and virtual keys, the database password and any secret in an environment variable. As Socket notes, “removing the package does not reverse credential exposure or terminate an already-running loader.”
BerriAI says it has revoked the tokens involved, temporarily removed all but one user from its GitHub organisation and cut its publishing links to PyPI and the container registries. Its private enterprise release was not affected.
Hijacked again
In March, versions 1.82.7 and 1.82.8 were published with a stealer after LiteLLM’s build pipeline ran a poisoned release of the Trivy security scanner, which leaked its PyPI publishing token. JFrog ties that campaign to a group known as TeamPCP but says nothing yet links it to this week’s attack, which used a different route and domain. No download figures for 1.107.0 have been published.
Why it matters
AI gateways put a company’s most valuable keys in one place, and those keys are worth real money: stolen Claude and Gemini logins already sell cheaply on the dark web. This time the attackers did not need a leaked publishing token: they used real engineers’ accounts to push malware through the project’s own release process, past the safeguards meant to stop exactly that.
Sources: LiteLLM incident report (October 21, 2026); LiteLLM GitHub issue #47826; SafeDep; Socket; JFrog Security Research; AISLE.
Latest More Labs news
