LiteLLM’s second hijacked release reached the keys behind the gateway

On 21 October 2026, an attacker took control of the release pipeline of LiteLLM, the open-source AI gateway built by BerriAI, and used it to publish version 1.107.0 to PyPI and Docker registries with an infostealer and a remote-access loader inside. According to the company’s incident report, the poisoned Python package was live from about 11:39 to 13:23 UTC, and the Docker tags v1.107.0, latest, main-latest and main-stable served it from about 11:46 until 14:20 UTC.

The post lists four authors: chief executive Krrish Dholakia, chief technology officer Ishaan Jaffer, director of security Oliver Jensen and lead Rust engineer Nate Armstrong. For Dholakia and Jaffer it is the second such account this year. On 24 March, versions 1.82.7 and 1.82.8 were pushed to PyPI by an attacker; LiteLLM paused new releases, brought in Google’s Mandiant for forensic analysis and shipped a clean version through a new CI/CD v2 pipeline.

Socket, whose scanner flagged the malicious wheels seven minutes after they were published, puts LiteLLM at about 23 million weekly downloads. After the March attack, the AI recruiting firm Mercor said it was one of thousands of companies affected, as The Register reported in April.

An AI gateway sits between a company’s applications and every model provider it pays for, so it is where those providers’ keys end up, sometimes alongside a cloud role with permission to call hosted models. A poisoned release of the gateway can read those keys and that role on every host where it runs. By LiteLLM’s account, its October compromise came after the hardening it carried out following March, through a temporary permission change and credentials sitting in its own logs, and for mid-market companies running the free build the exposure sits in a component that rarely passes through procurement or vendor review.

What the stealer went after

Wiz researchers Benjamin Read and Rami McCarthy list browser credentials, AWS, GCP and Azure credentials, API keys for AI providers, SSH keys and shell history among the targets, along with upstream provider credentials queried directly from the LiteLLM Proxy’s PostgreSQL database. Ilyas Makari of Aikido Security describes the second component as a remote access trojan that polls attacker infrastructure every hour and runs whatever Python code it is sent.

According to Wiz, between 16:20 and 17:01 UTC, roughly 4.5 hours after exfiltration, the attacker tested harvested AWS instance role credentials and then made model-listing calls, including to Amazon Bedrock. Socket’s researchers found that the malicious files run at Python startup even when an application never imports LiteLLM, and they set out the limit of a quick uninstall: “Removing the package does not reverse credential exposure or terminate an already-running loader.”

LiteLLM’s own guidance to open-source users goes as far: “If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded.” The rotation list that follows covers the instance or task role, every provider key in the proxy database, the master and virtual keys, the database password and any secret in the host’s process environment. Most items on it are credentials the gateway holds to control access to itself and to reach model providers.

A rebuilt pipeline, beaten again

The post is direct about what changed after the first incident: “After the prior incident in March, we meaningfully hardened our CI release pipeline.” Releases moved to a private repository, publishing ran through trusted GitHub publishers, Docker release tags were made immutable and images were signed. The attacker, the authors write, “had to compromise multiple independent security controls to be successful.”

On Monday 19 October, release permissions were temporarily widened so that two internal engineers could “publish daily bugfix backports for customers”. Separately, LiteLLM believes the attacker took developers’ GitHub CLI OAuth tokens from logs on an internal LiteLLM deployment, “which was exposed to the public internet”. There the team found “an unexpected, innocuously named user account”. LiteLLM has not confirmed how the attacker got in and suspects a recently patched vulnerability.

With three developer credentials, the attacker overrode branch protection at 10:08 UTC, repointed the release workflow at a lookalike repository, Berri-AI/litellm, and used a second credential to satisfy the production approval gate at 11:11. A third credential deleted workflow records shortly after the upload, limiting the logs available to investigators. The official v1.107.0 source tag on GitHub, the post says, never contained the malicious files.

A layer outside vendor review

Customers who pay for LiteLLM were not caught: “Enterprise Customers running the private enterprise release of LiteLLM were not impacted.” Open-source users who installed the package unpinned through pip or followed a floating Docker tag were. Socket notes that deployments following such a tag “could therefore receive the affected release”, which is how a gateway set up once and left to update itself took in the poisoned build without anyone choosing it. BerriAI did not respond to questions from The Register, the outlet reported on 21 October.

LiteLLM believes the March compromise came from the Trivy dependency in its CI security scanning workflow; October’s came through its own logs and a permission change made for its own customers. Both reached the same software, the gateway that holds the provider keys, the cloud role and the model spend of the companies running it.

LiteLLM’s incident report describes a release process that had been rebuilt with a private repository, trusted publishing and signed images, and that, by the company’s account, was still opened by a temporary permission change and tokens exposed in logs. For a mid-market board, part of the company’s AI risk now sits in a free gateway that an engineering team can install in minutes, that holds the keys to the model providers the company pays and whose official PyPI package has now carried malware twice in seven months.