What happened
LiteLLM disclosed on Friday that a master key to a deployment of its Agent Platform was committed to a public GitHub repository on 27 May 2026, inside a configuration file in the LiteLLM-Labs/lite-harness project. The error was spotted, the commit was force-pushed over, and the exposed keys were flagged for revocation. Every key was revoked except the master key.
An attacker working from 69.48.229[.]143 used it on 10 October to reach the Agent Platform and extract a GitHub CLI OAuth token that was not scoped down and belonged to the GitHub organisation owner, which carried owner-level access to every repository.
Socket's reconstruction fills in the middle. Two commits added a workflow at .github/workflows/cache.yml, each pushed to a throwaway branch that was created, used and deleted within minutes. The workflow harvested GitHub tokens, API keys for Linear, Together AI and the LiteLLM deployment, a GitHub App signing key, and a GitGuardian secret-scanning key. A second run added Anthropic and OpenAI keys, Bedrock credentials, a Playwright session state, and PostgreSQL and Redis connection details.
On 21 October the release pipeline was repointed at the lookalike repository Berri-AI/litellm. Version 1.107.0 reached PyPI at 11:39 UTC, images followed, Upwind reported the compromise at 12:06, PyPI quarantined the version at 13:23, and Docker Hub tags were repointed to clean images by 14:20. The control that should have caught it had been relaxed that week. Publishing normally needs an authorised engineer plus approval from a hardware-locked account in the office, but to speed up releases any two engineers could trigger and approve.
Microsoft found the package runs at Python startup even when LiteLLM is never imported, and the startup files sit outside the application directory.
Why this is a GRC story
Revocation is a workflow, not a decision. The key was flagged in May and still worked in October. Between the finding and the fix there was no owner, no deadline and no check that closed the loop. That gap is the incident.
Blast radius is a scoping decision. A service that files pull requests needs write access to one repository. It held an organisation owner's token instead, which turned one leaked secret into every repository.
Separation of duties went for release velocity. A hardware-locked approver is awkward to live with. It is also the control that would have stopped this. Relaxing a release gate for a busy week deserves the same review and expiry date as disabling a firewall rule.
Your secret scanner is a tier zero credential. The GitGuardian key was harvested with everything else, which gave the attacker sight of the alerts that would have surfaced the activity.
Uninstalling is not remediation. With a startup hook outside the application directory, the response is a host-level sweep and a full rotation of every credential that lived on those machines.
What to watch
Whether LiteLLM publishes the complete list of affected environments, and whether the release-approval change has been restored and documented. That answer says more about the project's control environment than the incident report does.
On your side, pull the list of CI tokens with organisation-level scope and the date each was last rotated, starting with the ones that only ever needed write access to a single repository.
Attribution: Analysis based on The Hacker News and related public reporting. This article is original commentary, not a repost of the source material.