LiteLLM’s maintainers confirmed that its release pipeline distributed credential-stealing malware in version 1.107.0 on October 21. The compromised Python packages and container images have been removed or replaced, but installed copies still require a response.

Which artifacts were affected

According to the maintainer incident report, all times below are UTC on October 21:

  • PyPI: seven litellm==1.107.0 wheels were available from 11:39:51 to 13:23.
  • Docker Hub: v1.107.0, latest, main-latest, and main-stable pointed to compromised images from 11:46:56 to 14:20.
  • GitHub Container Registry: affected tags were made unavailable by 13:51, after publication began at 11:46:56.

The maintainers say their private enterprise registry was unaffected. That distinction concerns the registry used, not whether an organization happens to be an enterprise customer. Cached malicious artifacts remain dangerous after the distribution window ends.

Why an ordinary reinstall is the wrong first move

The malicious files include Python startup hooks, code that runs when the interpreter starts. The maintainer report warns: “Don’t start with pip install.” Starting pip in an affected environment can run the malware again.

Wiz’s technical investigation describes theft of cloud credentials, browser data, SSH keys, AI-provider keys, and credentials accessible through the LiteLLM proxy database. The malicious build also included a loader for additional remote code. Wiz says it had not observed that dynamic second-stage payload active.

Exploitation status: malicious software was distributed; Wiz reports subsequent use of stolen credentials. Between 16:20 and 17:01 UTC, Wiz observed checks of stolen AWS identities and enumeration of model services. This is reported incident telemetry, beyond a laboratory demonstration. Wiz sells cloud-security software and services.

What the release signature did not establish

The maintainers say attackers used stolen developer credentials to override branch protections and redirect the release workflow to an attacker-controlled repository. The workflow then signed and published the poisoned artifacts. The legitimate GitHub source tag did not contain the malicious files.

A signature can establish which release machinery produced an artifact while that machinery is compromised. Reviewing the legitimate source tag alone would miss this particular substitution.

The suspected initial route remains under investigation. Maintainers believe GitHub CLI credentials appeared in logged Claude Code responses and were taken from an exposed internal LiteLLM deployment. They have not confirmed how the attacker first entered that deployment.

What affected operators should do

  1. Isolate affected environments and preserve evidence. Avoid starting Python or pip inside them as an initial diagnostic or cleanup step.
  2. Follow the maintainer’s recovery instructions from a clean environment. Prefer rebuilding affected environments and images from trusted sources; the report recommends pinning 1.106.2.
  3. Revoke or rotate accessible credentials, including cloud credentials, provider keys in the proxy database, and database passwords. Replacing the package does not revoke stolen secrets.
  4. Review downstream activity and build caches. Missing malware marker files do not prove that an environment escaped exposure.

Caveat: the initial-access account remains provisional, and “unaffected” earlier versions means unaffected by this malicious release—not free of every other vulnerability.

Based on the maintainer report updated at 20:30 UTC and Wiz’s reporting updated through 21:45 UTC on October 21. Later findings should amend this page rather than create a duplicate incident summary.

Update: October 21, the HN discussion adds recovery trade-offs

What the thread adds

The discussion of SafeDep’s investigation into the same incident adds questions about release controls and package-update policy:

  • aakashpawar distinguishes attestation from source integrity: “They prove which workflow published the wheel, not what source that workflow checked out.” The commenter proposes rebuilding from the public tag and comparing artifacts.
  • stbenjam proposes a default “cooldown for 24 - 48 hours” before installing new packages. This is a suggested policy, not a guarantee that a malicious release will be discovered in time.
  • robinhoodexe reports the corresponding cost: “We have 7d cooldown on packages on an internal pypi proxy but that blocks security updates also”. Their team manually exempts security fixes.
  • joshheitzman questions the provisional credential-leak account: “What did y’all have CC doing that it had your GitHub CLI OAuth token in its context at all?” The comment asks for a missing mechanism rather than establishing one.

From a 146-comment thread, in HN’s own order.