LiteLLM Says Attacker Had Repo Access 11 Days Before Rogue 1.107.0

LiteLLM's attack-chain post, published October 23 at 21:00Z, traces the 1.107.0 compromise to a LiteLLM Agent Platform master key committed to the public LiteLLM-Labs/lite-harness repo on May 27, 2026, and never revoked. On October 10, the attacker used that key to pull an unscoped GitHub CLI OAuth token belonging to the GitHub org owner, granting access to every repo in the organization. That single credential, sitting exposed for roughly four and a half months, is now the documented root cause, not the release pipeline itself.

With owner-level access in hand, the attacker ran secret-exfiltration workflows inside BerriAI/litellm and BerriAI/litellm-auto, stealing tokens from two maintainers along with credentials for other internal systems. Those stolen tokens sat unused until October 21, between 10:08 and 11:40Z, when branch protection was overridden and the release pipeline was repointed to a lookalike repository, Berri-AI/litellm, before 1.107.0 shipped to PyPI, Docker Hub, and GHCR. PyPI quarantined the package at 13:23Z that day. The gap between initial access and the actual release, eleven days, is the detail that changes how this incident gets read.

Anyone who pulled LiteLLM images or packages during that window is not just checking a release tag anymore. The exposure period now runs from October 10 through October 21, which means audit logs, pinned dependency hashes, and build caches covering that full span need review, not just the hours around the 1.107.0 publish. For pipelines that mirror PyPI or Docker Hub into internal registries, the lookalike repo detail matters: Berri-AI/litellm versus BerriAI/litellm is the kind of typo a human reviewer catches and an automated mirror job does not.

Operators moving data through LiteLLM-fronted services should treat the incident as a credential-handling failure with downstream interoperability consequences, not a packaging bug. A master key sitting in a public repo for months, then used to escalate to an org-owner OAuth token, is a chain that bypasses most artifact-level scanning entirely, since the signed packages themselves were never cryptographically broken, only redirected. What remains undisclosed is the full list of internal systems tied to the maintainer tokens that were exfiltrated, which leaves open how far lateral movement extended beyond the two repos named.

Known-good versions are 1.106.2 and the October 24 backports, 1.106.3, 1.105.4, 1.104.6, and 1.103.8, all signed with a new cosign key, which gives downstream consumers a concrete verification path going forward. LiteLLM has not disclosed a security record for this class of event, consistent with its description as a supply-chain compromise rather than a code vulnerability. For teams running automated upgrade policies, the lesson sitting underneath the new cosign key is that signature verification has to be enforced at pull time, not assumed from a version number, because the old pipeline proved that version numbers alone could be redirected.