Skip to content

Response, New York. Noah Park: Check Point Patches Actively Exploited Management Server Path Traversal. Detection, Dallas. Ava Okello: Report Finds Nearly Half of Deployed Detections Need Attention Before SOCs Can Trust Them.

SOCtember

Always First. Fast SOC News.

LiteLLM blog header graphic reading The attack chain behind the v1.107.0 LiteLLM release.
Image: LiteLLM, header of its root-cause report, Oct. 23, 2026 (fair use).

Response

LiteLLM Says Its Poisoned 1.107.0 Release Traces Back to a Master Key Leaked in May and Never Revoked, Which Handed an Intruder a GitHub Owner's Token 11 Days Before the Attack

The company's root-cause report drops its earlier theory that the tokens leaked through gateway logs. It shows how one unscoped GitHub CLI token let the attacker pull CI secrets, override branch protection, approve the release with a second maintainer's token and erase the run records with a third, and what responders should look for in their own GitHub audit logs.

Noah Park, ResponseNew York6 min read

NEW YORK - The poisoned version of LiteLLM that reached the Python Package Index and two container registries on Oct. 21 did not start with a clever exploit. It started with a key that was supposed to be revoked in May and was not, according to a root-cause report the open-source AI gateway project published on Friday.

The report, by Oliver Jensen, LiteLLM's director of security, and Mateo Wang, an AI engineer, replaces the explanation the company gave while the incident was unfolding. Its first post had suspected that GitHub tokens were taken from the logs of an internal LiteLLM deployment. "The request logs show the first token came from a different service," the company now says, and it calls the new report "the canonical source of truth."

A key that outlived its leak

On May 27, a configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key to a deployment of the LiteLLM Agent Platform, an internal tool the company used to have cloud agents open pull requests. "The error was quickly identified, 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 report says.

That platform held a GitHub CLI OAuth token belonging to one of the company's two GitHub organization owners. The token "was not associated with a service account and was not scoped down." On Oct. 10, from 69.48.229.143, the attacker made a series of authenticated calls to the platform's API between 21:13 and 21:28 UTC. At 21:27:10 a request for the list of managed agents returned the configuration of every agent, the owner's token included.

LiteLLM's Compromised Credentials table, listing the Agent Platform master key and three GitHub CLI tokens, how the attacker got each one and what each was used for.
Screenshot: LiteLLM, the Compromised Credentials table from its root-cause report, Oct. 23, 2026 (fair use).

LiteLLM notes that GitHub CLI tokens "are post-2fa and not subject to GitHub's 'super-user' 2fa reauth flows associated with sensitive organization or repository actions." From that point the attacker had owner-level access to every repository in the organization.

Turning CI into the exfiltration channel

Less than an hour later the attacker used the project's own build system against it. At 22:11:45 a workflow on a throwaway branch named ci-tmp-a351cc in BerriAI/litellm posted six repository secrets to an attacker-controlled webhook[.]site endpoint. One of them, GH_TOKEN, held the GitHub CLI token of a second maintainer. Twenty-four seconds later a workflow on branch ci-tmp-be33e9 in BerriAI/litellm-auto posted RELEASE_PLEASE_TOKEN, the token of a third maintainer. Both runs were deleted within three minutes. On Oct. 12, between 12:08 and 12:30, workflows on a variety of private repositories posted all of their secrets to the same endpoint.

The report says the attacker also obtained tokens to several other internal systems and that activity there focused on "upstream inference API tokens."

LiteLLM's detailed timeline in UTC, from the May 27 commit of the master key through the Oct. 10 exfiltration workflows and the Oct. 21 branch protection override and staging run.
Screenshot: LiteLLM, the first rows of the detailed timeline in its root-cause report, Oct. 23, 2026 (fair use).

Eleven days later, the release

The attacker waited until Oct. 21. Working from 199.91.221.39, they tried at 10:08:29 UTC to push a change that let the private BerriAI/project-releaser workflows build from a repository other than BerriAI/litellm. Branch protection, which requires a pull request, two passing checks and the code owner's approval, rejected the push. Five seconds later the attacker disabled the protection with the owner's token and force-pushed.

At 10:46:39 they dispatched the staging workflow with its source set to a lookalike organization, Berri-AI/litellm, at commit 20535d8f. That commit existed only on the attacker's fork, but it opened under the official repository's URL "because GitHub serves a fork's commits through the repository it was forked from," the report says.

Normally a release must be started by an authorized engineer and approved by a special account locked to a physical device in the office. That rule had been relaxed earlier in the week to speed up bug-fix backports, allowing any two engineers to trigger and approve a release. At 11:11:18 the second maintainer's token approved the production gate. Seven wheels went to PyPI between 11:39:51 and 11:40:13, and Docker Hub and GHCR images followed at 11:46:56. At 11:53:49 and 11:54:01 the third maintainer's token deleted the production and staging run records, removing their workflow logs. Between 12:09 and 12:24 the attacker reverted the change and force-pushed main back to its earlier state, again overriding protections.

LiteLLM believes the attacker used separate identities "in order to evade detection by way of noisy audit logs."

Caught by an outsider

A community member, LidorMachluf, opened GitHub issue #47826 at 12:06:41 identifying the compromise. LiteLLM began incident response at 13:02, PyPI quarantined the release by 13:23, and the Docker Hub tags were removed or repointed by 14:20. The company says the artifacts were live for about two hours. It locked its registries, removed every member of its GitHub organization except one account it trusted and temporarily promoted to owner, and is revoking every token for every internal system and vendor platform. "This incident has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key," the report says. LiteLLM says it will describe process changes next week.

LiteLLM's Indicators table listing the two attacker IP addresses, the lookalike organization Berri-AI, the fork commit, the two exfiltration branches and the hidden workflow and revert commits.
Screenshot: LiteLLM, the Indicators table from its root-cause report, Oct. 23, 2026 (fair use).

What responders can do

  • If any system installed litellm 1.107.0 or pulled the affected images, follow LiteLLM's incident post for exposure checks and cleanup and rotate every secret those hosts could read.
  • Treat a key that was ever committed to a public repository as compromised even after a force-push, and confirm revocation at the issuing service rather than in the repository.
  • In GitHub organization audit logs, look for branch protection and force-push overrides, workflow runs on short-lived branches, and deleted workflow runs. LiteLLM notes that the audit log records a hash of the token behind each action, which is how it tied each step to a specific stolen token.
  • Search for the published indicators: 69.48.229.143, 199.91.221.39, the lookalike organization Berri-AI, commit 20535d8f and the branches ci-tmp-a351cc and ci-tmp-be33e9.
  • Keep personal owner-level GitHub CLI tokens out of agent platforms and CI secrets, and prefer scoped service identities for automation.

Sources:


Noah Park covers incident response, containment, and blue-team operations for SOCtember from New York.

Related stories

Response desk