LiteLLM Revises Its 1.107.0 Breach Account, Tracing Entry to a Master Key Committed in May; Socket Finds Secret-Stealing Workflows Ran October 10

Overview

LiteLLM has published a root-cause analysis of the October 21 compromise of its 1.107.0 release that changes the account it gave on the day. In the new post, LiteLLM traces the intrusion to a master key committed to a public repository on May 27 and never revoked, and says the attacker began stealing credentials on October 10, 11 days (by the Herald’s own count) before the malicious package appeared on PyPI. The Machine Herald previously reported the October 21 release and the project’s first explanation; this article covers what has since been revised.

What LiteLLM Now Says

The October 23 post is written by Oliver Jensen, Director of Security, and Mateo Wang, AI Engineer, both of LiteLLM. It states that “some assumptions and beliefs in those updates were later proven to be inaccurate or incomplete. This post is the canonical source of truth,” according to LiteLLM. The original incident post now carries a notice with similar wording.

The earlier explanation held that the attacker had obtained GitHub CLI tokens from the logs of an internal LiteLLM deployment, and said LiteLLM had not confirmed how the attacker reached that deployment but suspected a recently patched vulnerability, according to the incident post. The new post says: “Our first post suspected the tokens were taken from the logs of an internal LiteLLM deployment. The request logs show the first token came from a different service,” as LiteLLM wrote.

According to LiteLLM, that service was the LiteLLM Agent Platform, which it describes as an experimental project for self-hosted cloud agents to file pull requests. The post says a configuration file committed on May 27 to the public LiteLLM-Labs/lite-harness repository inadvertently contained the platform’s master key, the commit was force-pushed over, and the exposed keys were identified as needing revocation. The post then says: “However, key revocation did not occur for the master key.” The platform was configured with a GitHub token that “was not associated with a service account and was not scoped down,” the post says, and it was a GitHub CLI OAuth token tied to a GitHub organization owner’s account.

The Reconstructed Sequence

LiteLLM says that on October 10 the attacker used the master key to call the Agent Platform API, and that a request at 21:27:10 UTC returned the organization owner’s token. With that token, the post says, the attacker pushed branches to run workflows that posted CI secrets to an attacker-controlled webhook.site endpoint. One such secret, GH_TOKEN, held a second maintainer’s token; another workflow, in the BerriAI/litellm-auto repository, posted RELEASE_PLEASE_TOKEN, which held a third maintainer’s token. LiteLLM says the attacker deleted both workflow runs within minutes.

The first of those workflows is visible in the public repository. The commit b69bc36 is dated October 10, 2026 at 22:11:45 UTC, carries the message “ci: bump cache config” and adds a 24-line .github/workflows/cache.yml. It reads six secrets, including GH_TOKEN, writes them to a file, base64-encodes the file and posts it to webhook.site with a trailing || true, according to GitHub’s commit data. A second commit, 1a6e3c1, dated October 12 at 12:16:00 UTC, adds a 97-line version of the same file with six jobs. Its first job reads secrets named ANTHROPIC_API_KEY and OPENAI_API_KEY, among others. LiteLLM characterizes that second round as having exfiltrated “some minimally sensitive secrets and minimally funded provider keys used in our CI testing,” and says those secrets were not part of the path to the poisoned artifacts.

The post credits Socket for an independent investigation of these workflows. LiteLLM lists October 22 at 17:38 UTC as the time the Socket team reached out. Socket published its own timeline on October 23.

How the Release Was Published

On October 21 at 10:08:29 UTC, LiteLLM says, a push to its private BerriAI/project-releaser repository, commit 9cf97e9 (“ci: release from a fork source repository”), was rejected by branch protection that requires a pull request, two passing checks and codeowner approval. Five seconds later the owner’s token was used to disable protections and force-push the change, the post says. The staging workflow then ran with the source set to the lookalike Berri-AI/litellm repository at commit 20535d8f, and a second maintainer’s token approved the production gate at 11:11:18 UTC.

The post attributes the loosened gate to a temporary change: publishing normally required approval by “a special account locked to a physical device in our office,” a restriction that “was relaxed earlier this week to accommodate the temporary push for more frequent releases and bugfix backports, allowing any two engineers to trigger and approve a release.” LiteLLM adds that an owner’s token could have removed the restriction outright, and says it believes the attacker used separate tokens “in order to evade detection by way of noisy audit logs.” The post says seven wheels reached PyPI between 11:39:51 and 11:40:13 UTC, and that a third maintainer’s token deleted the production and staging run records at 11:53:49 and 11:54:01.

Afterward, LiteLLM says, the attacker pushed a revert and then force-pushed main back to the commit before the change, overriding GitHub’s force-push block, leaving both commits retrievable by SHA. The post thanks the reporter of GitHub issue 47826, LidorMachluf, who opened it at 12:06:41 UTC on October 21 according to GitHub.

What We Don’t Know

• The post says LiteLLM will share its process changes “next week”; no specifics were published in the root-cause analysis.
• The attacker’s identity is not given in the post, and the Herald found no attribution in the sources reviewed.

Lessons the Post Draws

LiteLLM writes that the incident “has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key,” and says it is now revoking every token associated with every internal system and vendor platform, as reported by LiteLLM.