News · 2026-10-22

LiteLLM’s trusted release workflow published poisoned Python wheels

LiteLLM’s October 21 release was compromised after an attacker used stolen developer credentials to redirect its release workflow to a lookalike repository. The resulting Python wheels contained a credential stealer and a background loader, even though the official source tag lacked the malicious payload. The incident exposes a gap between a trusted publisher and trustworthy release contents.

Key facts

• Seven poisoned PyPI wheels were available for about one hour and 43 minutes on October 21.
• The affected release was LiteLLM 1.107.0; affected Docker Hub tags persisted until 14:20 UTC.
• Maintainer BerriAI says a stolen organization-owner credential changed the release workflow.
• The primary source is BerriAI’s incident report.

The decisive detail is the repository name. According to BerriAI, the workflow was changed to build from a lookalike source repository rather than the official project. The attacker did not need to insert the payload into the public tag reviewers would naturally inspect. A legitimate publication system then signed and shipped artifacts built from the redirected source. BerriAI describes the use of “Trusted GitHub Publishers,” showing why an authenticated publication path cannot by itself establish that the intended code was built.

Imagine a factory with an approved shipping seal but a compromised instruction telling it to collect goods from a counterfeit warehouse. The seal may accurately identify the factory. It says much less about the goods unless the record also binds them to the expected source and build instructions. This is the distinction the maintainer’s technical issue makes operationally important.

The initial access story remains partly unresolved. BerriAI says the attacker possessed GitHub command-line OAuth credentials belonging to three developers. It believes they were exposed through logs in an internal LiteLLM deployment reachable from the public internet. In some circumstances, Claude Code could include a user’s credential in a response body, and logging that body could retain it. BerriAI found an unexpected account but had not confirmed how the attacker initially entered the deployment.

That uncertainty should remain visible. It does not undermine confirmation of the malicious release, but it prevents a clean claim that a particular vulnerability was the proven entry point. BerriAI also says it had temporarily broadened release permissions for customer backports. An owner-level credential could disable branch protection and change the private workflow. A chain of permissions and stored secrets therefore mattered as much as the package manager itself.

SafeDep’s static analysis found a startup hook that imported the stealer when Python started in an affected environment. Applications did not have to make an ordinary LiteLLM call first. The payload targeted cloud and automation credentials, SSH keys, browser secrets, AI developer-tool tokens and environment variables. Where a database connection was available, it also sought provider keys in LiteLLM’s proxy database.

A separate startup component launched an hourly background loader capable of fetching and executing another payload. The sources did not establish that it received operational commands: the relevant dead-drop file was empty when BerriAI reported, and SafeDep could not recover a server address. That limit concerns the second-stage path. It does not erase the separate credential-stealing capability or establish that an internet-connected affected host was safe.

The artifact distinction is unusually important. The poisoned payload was in the seven wheels. The source archive listed by PyPI had a build-setting change but not that payload folder. Neither the clean official tag nor a different archive provides reassurance about an installed wheel. There is no verified download total in the dossier, so package popularity and discussion traffic should not be converted into an estimate of affected organizations.

BerriAI’s remediation guidance treats affected environments as compromised. Its instructions warn against first starting Python or running the package installer there, because startup itself can trigger the payload. Recovery includes removing startup components through the shell, stopping the detached process, rebuilding an environment or image, and rotating the secrets that host could access. The report identifies 1.106.2 as the recovery pin in its guidance.

The Hacker News discussion included calls for sandboxing, restricted networking and keeping valuable credentials outside processes running third-party tools. Those are practitioner reactions, not evidence of measured migration. They connect directly to scoped agent credentials and sandboxing: the damage boundary is the authority of the compromised environment. A trusted release identity remains useful, but source selection, build controls and secret isolation must carry their own guarantees.

Primary source, verified: read the paper →

Ground Truth. (2026, October 22). LiteLLM’s trusted release workflow published poisoned Python wheels. Ground Truth. https://groundtruth.day/news/litellm-poisoned-wheels-release-workflow.html

@misc{groundtruth:litellm-poisoned-wheels-release-workflow,
  title  = {LiteLLM’s trusted release workflow published poisoned Python wheels},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/litellm-poisoned-wheels-release-workflow.html}
}

Topics: cybersecurity · ai-security · supply-chain · credentials · litellm