Unrevoked LiteLLM Master Key from May Commit Enabled October GitHub Token Theft and v1.107.0 PyPI Poisoning

The attacker first used the key to run two deleted workflows on October 10 that exfiltrated maintainer tokens via webhook.site. On October 21 the actor overrode branch protection, redirected the release source to Berri-AI/litellm, and obtained approvals from the stolen tokens to push the poisoned package to PyPI at 11:46 UTC. Docker images followed before deletion of production logs. LiteLLM stated the key revocation step was skipped after the initial force-push, while the release process had been relaxed days earlier to allow any two engineers to approve.

Evidence shows the workflows were engineered to harvest upstream inference tokens, not merely to publish one version. Socket recovered the exact malicious .github/workflow files that added the exfiltration steps. Official statements emphasize quick detection of the May commit yet omit any log review confirming the key remained active for five months. Independent timeline reconstruction from GitHub audit logs and PyPI quarantine records matches the attack sequence but reveals no independent verification that the malicious repository link was the only change introduced.

This incident follows the pattern of supply-chain compromises where long-lived service tokens with organization-wide scope survive initial exposure. Similar token leakage occurred in the 2024 XZ Utils backdoor attempt and the 2025 GitHub Actions artifact poisoning cases. The LiteLLM Agent Platform's design to let cloud agents file pull requests without scoped permissions created the direct path from one leaked key to full release control.

LiteLLM reports it is now revoking every internal and vendor token. Next steps include mandatory hardware-bound approvals and elimination of the two-engineer release shortcut. Regulators and downstream package consumers should monitor whether the new controls survive the next push for rapid releases.