The LiteLLM hack started with a coding-agent config file. The leaked key was force-pushed over, never revoked.

When litellm==1.107.0 showed up on PyPI with a credential stealer inside on October 21, the first theories pointed at logs. LiteLLM's own first update suspected GitHub tokens had been scraped from an internal deployment's logs. Its final root-cause report (opens in a new tab), published October 23 and described as "the canonical source of truth," tells a plainer story: a key leaked in May, got hidden instead of revoked, and opened a door to an agent that had far more power than it needed.

Step zero: a config file. On May 27, an opencode.json file (a config for the OpenCode coding agent) was committed to the public LiteLLM-Labs/lite-harness repository. It contained the master key to a deployment of the LiteLLM Agent Platform, an experimental, self-hosted tool for agents that file pull requests. In LiteLLM's words, "the commit force-pushed over, and we identified the exposed keys as requiring revocation. However, key revocation did not occur for the master key."

The agent held the keys to everything. To open PRs, the platform was configured with a GitHub token that "was not associated with a service account and was not scoped down." It was a GitHub CLI OAuth token belonging to one of LiteLLM's two GitHub organization owners. LiteLLM notes that GitHub CLI tokens are post-2FA and skip the extra re-authentication GitHub asks for on sensitive actions.

October 10: 136 days later. The attacker called the Agent Platform API with the master key. One request, GET /api/v1/managed_agents/agents?limit=100, returned every managed agent's configuration, including the owner's token. From then on, the attacker had owner-level access to all of LiteLLM's repositories.

CI as the exfiltration channel. Within the hour, the attacker pushed throwaway branches whose workflows posted repository secrets to a webhook.site endpoint, then deleted the runs. That yielded the GitHub CLI tokens of two more maintainers, stored as repo secrets. Two days later, a second round hit several private repos.

October 21: the release. LiteLLM had relaxed its release rules earlier that week so that any two engineers could trigger and approve a release, to ship fixes faster. The attacker overrode branch protection with the owner's token, pointed the release workflow at a lookalike fork, Berri-AI/litellm, used one stolen token to trigger and another to approve. Seven wheels went to PyPI between 11:39 and 11:40 UTC (about 4:40am Pacific), with Docker images minutes later. A third token deleted the run records, and the owner's token force-pushed the workflow history clean.

Who caught it. GitHub user LidorMachluf opened issue #47826 (opens in a new tab) at 12:06 UTC, about 27 minutes after the wheels went up. PyPI quarantined the release by 13:23 UTC; the Docker tags were pulled by 14:20 UTC. Microsoft's analysis (opens in a new tab) says the payload ran at Python startup, so even running pip in an affected environment could trigger it. We covered the payload and cleanup here and how to check your environment here.

Our take

Every AI coding setup now comes with config files full of keys: agent configs, MCP server configs, .env files the agent helpfully created. They get committed by accident all the time. The fix most people reach for is the one LiteLLM reached for: rewrite history and move on. That makes the key invisible to you, not to whoever already cloned or scraped it.

The second mistake is the bigger one. An experimental agent that only needed to open PRs was running on an organization owner's personal, unscoped token. When the agent's key leaked, the owner's account leaked with it.

None of this needed a clever exploit. It needed one skipped rotation and one convenience token.

What to do

• If a secret ever touched a public commit, revoke and rotate it. Deleting or force-pushing the commit is not a fix.
• Give agents their own scoped credentials: a GitHub App or fine-grained token limited to the repos and permissions they need, never a human owner's CLI login.
• Keep agent and MCP config files out of git (add them to .gitignore) and run a secret scanner on commits.
• Don't loosen release approvals "temporarily" without a date to restore them.

LiteLLM says it will share its process changes next week. It also says it is revoking every token tied to every internal system and vendor platform.