LiteLLM Hit by Second Supply Chain Attack as Hijacked Pipeline Ships Credential Stealer

LiteLLM has confirmed that attackers hijacked its release pipeline on Oct. 21 and published a malicious litellm==1.107.0 package to PyPI, along with poisoned Docker Hub and GitHub Container Registry images, that stole cloud, AI and developer credentials.

According to the LiteLLM incident post, the PyPI release was live from 7:39 a.m. to 9:23 a.m. ET. Images tagged v1.107.0, latest, main-latest and main-stable pointed to the compromised build from 7:46 a.m. ET until 9:51 a.m. ET on GitHub Container Registry and 10:20 a.m. ET on Docker Hub.

It is the second time in 2026 that LiteLLM’s distribution channel has been turned against its users. In March, malicious versions 1.82.7 and 1.82.8 reached PyPI through the Trivy compromise, an incident the FBI later tied to TeamPCP and that CloudSEK estimated potentially exposed more than 2,500 organizations. LiteLLM has not attributed the October attack to any threat actor.

A leaked master key handed attackers owner access

In a root cause analysis published Oct. 23, LiteLLM traced the intrusion to May 27, when a configuration file committed to its public LiteLLM-Labs/lite-harness repository exposed the master key for an internal LiteLLM Agent Platform deployment. The commit was force-pushed over, but the key was never revoked.

On Oct. 10, the attacker used that key to pull a GitHub CLI OAuth token belonging to one of LiteLLM’s 2 GitHub organization owners. Less than an hour later, throwaway branches on BerriAI/litellm and BerriAI/litellm-auto ran workflows that posted CI secrets, including tokens for 2 more maintainers, to a webhook.site endpoint. LiteLLM’s first update had blamed tokens leaked into logs of an exposed internal deployment, a theory the company has since corrected.

Stolen tokens rerouted the build to a lookalike repository

At 6:08 a.m. ET on Oct. 21, branch protection blocked a change to LiteLLM’s private BerriAI/project-releaser workflow. The attacker overrode it 5 seconds later with the owner’s token and force-pushed the change so releases could build from another repository.

The build was pointed at Berri-AI/litellm, a lookalike fork one hyphen away from the legitimate BerriAI/litellm, and a second maintainer’s token approved the production gate. LiteLLM had relaxed its controls that week so any 2 engineers could trigger and approve bugfix releases, bypassing its usual approval from an account locked to a device in its office. The pipeline then signed and published 7 malicious wheels.

A third stolen token deleted the workflow run records, and the attacker force-pushed the release repository’s history clean. The official v1.107.0 source tag never contained the malicious files. An independent researcher flagged the compromise in a public GitHub issue at 8:06 a.m. ET.

Python startup hooks ran the stealer without an import

Each wheel dropped cook.pth, cook.py and sitecustomize.py into site-packages. According to Microsoft’s analysis, Python runs these files at interpreter startup, so the payload fired whenever Python launched, even if nothing imported LiteLLM. In one Windows case, installing an unrelated dependency triggered it.

The collector, which calls itself PRIVCOLLECT, targeted AWS, Azure and Google Cloud credentials, Kubernetes and Docker secrets, SSH keys, browser data and authentication files for AI coding tools, and tried to read stored provider keys from the LiteLLM proxy database. Stolen data was encrypted and posted to www.litellm[.]dev/healthcheck.

A separate Unix loader in sitecustomize.py polled a GitHub-hosted file for a server address to fetch more Python code. Microsoft said no second-stage execution was confirmed, but the mechanism could be re-armed.

LiteLLM sits between applications and model providers, often holding every upstream API key an organization uses. LiteLLM said customers on its private enterprise release were not affected.

What LiteLLM users should check now

LiteLLM says anyone who installed an unpinned version or started an affected image during those windows should assume compromise. LiteLLM and Microsoft recommend:

• Do not run pip or python inside a suspect environment, since any interpreter start reruns the payload. Investigate from a clean system.
• Search site-packages, pip and uv caches, mirrors and images for litellm-1.107.0.dist-info, cook.pth, cook.py and sitecustomize.py, and check for image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.
• Kill the daemon holding /tmp/remote_code_loader.lock. The marker /tmp/.pc_once_72129118c59f5636c0bb confirms exfiltration, but its absence proves nothing.
• Rebuild from scratch, pinned to litellm==1.106.2 or another explicit pre-incident version.
• Rotate everything the host could reach, including IAM roles, provider keys stored in the proxy database, master and virtual keys, and the DATABASE_URL password.
• Review CloudTrail for GetCallerIdentity calls around install time, then for outside use of those credentials, and hunt for connections to www.litellm[.]dev.

An unrevoked key became a poisoned release

“This incident has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key,” LiteLLM wrote.

That pattern runs through 2026’s biggest supply chain incidents. BreachNews previously reported how secrets stolen in earlier compromises fueled secondary breaches, and how incomplete credential rotation preceded the cyberattack that pushed Zeabur into shutdown after attackers hunted for AI service keys. The Bitwarden CLI compromise and the Mini Shai-Hulud campaign showed that signed packages are only as trustworthy as the pipeline behind them, and the March LiteLLM compromise reached AI training vendor Mercor.

LiteLLM said it removed all members from its GitHub organization, is revoking every token tied to its internal systems and vendor platforms, and will share process changes next week.