-
Attackers published a poisoned LiteLLM version, 1.107.0, on Oct. 21. It stole passwords and keys and could run the hackers’ code.
-
LiteLLM suspects the hackers found GitHub tokens in logs on an internal server that was open to the internet.
-
Users with version 1.107.0 installed need to remove it and change all passwords and keys the infected machine had access to.
LiteLLM is a popular open-source tool that links apps to AI models. On Wednesday, the company admitted that hackers took over its release process and slipped a poisoned version to users.
LiteLLM now suspects the break-in began with login tokens that leaked into its own logs. Meanwhile, researchers have watched the attackers test stolen cloud keys.
Details of the attack and how the attackers gained access
The attack hit early on Oct. 21. Attackers published version 1.107.0 to PyPI, the main download site for Python software. They also pushed it to Docker Hub and GitHub’s container registry. In Docker, the malicious code sat under four tags — v1.107.0, latest, main-latest and main-stable.
Two groups faced risk. First, anyone who installed LiteLLM with pip, without locking a version, between 11:39 a.m. and 1:23 p.m. UTC. Second, anyone who pulled the Docker image between 11:46 a.m. and 2:20 p.m. UTC. PyPI removed the release in under two hours. Even so, any machine that ran the code needs a close look.
LiteLLM had tightened security after a similar attack in March. It moved releases to a private repository, made Docker tags permanent, and began signing Docker images. However, a short-term change opened a gap. On Oct. 19, the team temporarily widened release rights for two engineers so they could publish daily bug fixes for customers.
The attacker already held three sets of developer GitHub login credentials. One set could run GitHub workflows. Then the attacker used a token from a GitHub organization owner to turn off branch protections and force changes.
Next, the attacker ran the release workflow against a lookalike repository, “Berri-AI/litellm.” The real one is “BerriAI/litellm.” As a result, the system signed and published the poisoned files.
Where the tokens may have leaked
LiteLLM says its logs may explain the theft. In some cases, it said, Claude Code puts a user’s GitHub token into a response. When a system saves those responses, the token can land in the logs. LiteLLM also found an “unexpected, innocuously named user account” on an internal deployment that was open to the public internet.
The company suspects the attacker entered that deployment, copied tokens from the logs, and used them on the release pipeline. Still, big questions remain. LiteLLM does not know why the deployment was public or how the attacker got in. Its best guess is a recently patched flaw.
How the Malware works
The poisoned package hid a startup file called cook.pth. Python runs it every time it starts, even if you never use LiteLLM. That file launches a script that hunts for secrets. It targets system data, browser data, developer tools, cloud accounts and AI tool keys. Then it sends the loot to litellm[.]dev, a site the real project does not own.
The package had a second part. On Linux and Mac machines, it checked a GitHub page for the attacker’s server address. If it found one, it downloaded more code and ran it every hour.
In a separate campaign, researchers warned that fake GitHub repositories were spreading BoryptGrab malware, highlighting how attackers abuse developer platforms to distribute malicious code.
That gives an attacker remote control. However, Wiz said the page held only test values before GitHub removed it. Meanwhile, JFrog said the stealer did not depend on that page.
Attackers put the stolen keys to the test
The thieves moved fast. About 4.5 hours after the theft, Wiz saw them test stolen Amazon Web Services keys taken from build servers and Kubernetes machines. The tests came from two IP addresses between 4:20 p.m. and 5:01 p.m. UTC.
The attacker checked each key’s identity, then listed AI models on Amazon Bedrock. Wiz called this consistent with “LLMjacking,” where criminals run up someone else’s AI account. In a few cases, the attacker also listed accounts, users and access keys.
Does the latest attack have a link to a March attack?
The attack looks familiar. In March, poisoned LiteLLM versions also used a startup file, and researchers blamed a group called TeamPCP. Socket, however, sees no proof of a link.
The encryption keys differ, and so do the data-theft and backdoor code. Still, Socket said the same group could have used new tools. Nobody has verified whether keys stolen in March played a role.
Possible next step
First, check for version 1.107.0 and remove it. Next, cut that machine off from your network. Then look for the malicious files and block litellm[.]dev. Change every password, token and key the machine could reach. Also check whether anything ran from “/codepy.”
JFrog researcher Guy Korolevski warned that a clean source repository says little about the file you actually install. So verify exact files before they reach your builds. If 1.107.0 ran anywhere, rebuild.
One exposed server may have undone months of security work. LiteLLM’s fixes after March did not stop this attack. Teams that depend on open-source tools should lock their versions and watch who can publish them.
