A LiteLLM Agent Platform master key sat exposed in the public repo LiteLLM-Labs/lite-harness since May 27, 2026, and nobody revoked it. That single fact, confirmed in LiteLLM's attack-chain post published Oct 23 at 21:00Z, is why this incident is bigger than a bad package release. On Oct 10 an attacker used that key to pull an unscoped GitHub CLI OAuth token belonging to the org owner, giving them access to every repository in the organization. The compromise of 1.107.0 on Oct 21 was the visible event. The actual breach started eleven days earlier.
For on-call engineers, the decision this forces is not just which package version to pin. It is whether to treat anything pulled from BerriAI's GitHub org, PyPI, Docker Hub, or GHCR between Oct 10 and Oct 21 as trustworthy. LiteLLM's post states the attacker ran secret-exfiltration workflows inside BerriAI/litellm and BerriAI/litellm-auto to steal tokens from two maintainers plus credentials for unspecified other internal systems. The company has not disclosed what those other systems are. That gap matters: if credential reuse extended beyond GitHub, the blast radius could include infrastructure nobody has named yet.
The mechanics are now documented in sequence. With maintainer tokens in hand, the attacker overrode branch protection between 10:08 and 11:40Z on Oct 21, repointed the release pipeline to a lookalike repository, Berri-AI/litellm, and published the poisoned build to PyPI, Docker Hub, and GHCR. PyPI quarantined 1.107.0 at 13:23Z the same day. That is fast containment once the bad release landed, but it says nothing about what the attacker touched during the prior eleven days of owner-level repo access. Branch protection overrides and pipeline repointing are the kind of actions that leave audit logs; whether LiteLLM has published those logs is not something the post addresses.
What changes operationally is the scope of the pull-request and CI audit. Checking build logs from Oct 21 alone is no longer sufficient. Anyone running LiteLLM in production needs to review dependency installs, CI runs, and any automated pulls from BerriAI repos going back to Oct 10, not just the release date. Known-good versions are 1.106.2 and the Oct 24 backports, 1.106.3, 1.105.4, 1.104.6, and 1.103.8, all signed with a new cosign key. That new signing key is itself a signal: it means the old key material is considered burned, so any verification pinned to prior keys will now fail and needs updating, not just the version pin.
This was a supply-chain compromise with no prior security record attached to the project, which is part of why a leaked key from May sat live for nearly five months. LiteLLM's post is the primary account and the company says it opened the investigation and supports the published timeline, which raises confidence in the sequence of events described. What it does not confirm is the full list of internal systems whose tokens were stolen alongside the two maintainers' credentials. Until that list is published, teams should treat the Oct 10 to Oct 21 window as the audit boundary, not Oct 21 alone.