LiteLLM traces its poisoned release to an admin key leaked in May and never revoked

LiteLLM published the attack chain behind its malicious 1.107.0 release on October 23. On May 27 an opencode.json file holding an administrative key for the internal LiteLLM Agent Platform was committed to the public LiteLLM-Labs/lite-harness repository. A follow-up commit deleted it about three hours later, but the file stayed in public history until October 22 and, in LiteLLM's words, "nobody followed through on revoking the administrative key." On October 10 an attacker used the key, and an agent-listing API call returned the GitHub CLI OAuth token of one of two organization owners. LiteLLM says that token is unscoped and is not subject to GitHub's 2FA re-authentication for sensitive actions. Within an hour the attacker ran workflows that posted CI secrets, including two more maintainers' tokens, to an external endpoint. On October 21 those tokens overrode branch protection, approved the production gate and published the release.

Why it matters

Deleting a leaked secret from a repository is not remediation; revoking it is. One forgotten key chained into three human-linked tokens because the agent platform stored an org owner's personal token instead of a scoped credential, and because two engineers' tokens satisfied a recently relaxed release approval rule.

Treat any secret that reached a public commit as compromised, even after a force-push, and rotate it the same day (secrets in repositories and CI covers the pattern). Never give automation an owner's CLI token: use a GitHub App or a fine-grained token scoped to the repos it needs. Keep CI secrets out of workflows that run on unprotected branches, and require release approvals from identities that cannot also trigger the build. Our October 21 post covers cleanup for affected installs.

Source: LiteLLM