Leaked LiteLLM Master Key Let Attackers Steal GitHub Tokens and Hijack Release Pipeline

Summary

According to the supplied report, the LiteLLM supply-chain compromise began with a credential exposure rather than a documented software exploit. An Agent Platform master key was accidentally committed to a public repository on May 27, 2026. Although the commit was overwritten, the key remained valid. On October 10, an unidentified attacker reportedly used it to enter the platform and extract an insufficiently scoped GitHub CLI OAuth token associated with a GitHub organization owner. That credential enabled access across the organization's repositories and further credential theft through malicious GitHub Actions workflows.^[0]

The attacker subsequently redirected the release pipeline to the lookalike repository Berri-AI/litellm and used two stolen engineer tokens to trigger and approve a malicious release. LiteLLM 1.107.0 reached PyPI on October 21, 2026, between 11:39 and 11:40 UTC, followed by Docker Hub and GHCR images at 11:46 UTC. The two-person release approval requirement had temporarily replaced a more restrictive physical-device approval process, but the maintainers also noted that the stolen organization-owner token could have enabled the attacker to change the restrictions directly.^[0]

The malicious package reportedly executed through Python startup mechanisms even when LiteLLM was not imported. Its capabilities included broad credential harvesting and a Unix-oriented background backdoor that fetched and executed attacker-supplied code hourly. Compressed stolen data was sent to litellm.dev. Exposure therefore extended beyond applications actively invoking LiteLLM, and removing only the LiteLLM application files could leave malicious startup components behind.^[0]

The reported response included PyPI quarantine of version 1.107.0, removal or repointing of affected Docker Hub tags, and an effort to revoke tokens across internal systems and vendor platforms. These conclusions rest on one supplied news report; linked investigations were not separately supplied as evidence. Two chronology discrepancies remain unresolved: the dates of the credential-stealing workflow activity and an apparently inconsistent year on the Docker Hub remediation timestamp.^[0]

Attack chain

1. 1. Public exposure of a still-valid master key: A configuration file committed to the public LiteLLM-Labs/lite-harness repository on May 27, 2026, contained the master key for an Agent Platform deployment. The exposing commit was force-pushed over, but the master key was not revoked, leaving the credential usable.^[0]
2. 2. Agent Platform access and GitHub owner-token theft: On October 10, the attacker reportedly connected from 69.48.229.143 using the exposed key. The attacker extracted a GitHub CLI OAuth token configured for agents to file pull requests. Because it was insufficiently scoped and belonged to an organization owner, it provided owner-level access across the organization's repositories.^[0]
3. 3. Push-triggered workflow injection and additional credential collection: The report describes malicious workflows in BerriAI/litellm and BerriAI/litellm-auto that sought additional credentials, including two maintainer tokens. Socket's recovered commits dated October 10 and October 12 added .github/workflows/cache.yml to short-lived ci-tmp- branches based on legitimate commits. A push triggered execution, collected secrets were directed to webhook.site endpoints, and the branches were deleted shortly afterward. The article's earlier chronology instead places two runs on October 10; the supplied evidence does not reconcile the accounts.^[0]
4. 4. Release-source redirection: On October 21, between 10:08 and 11:08 UTC, the attacker reportedly overrode branch protection and changed the release pipeline's source from the legitimate BerriAI/litellm repository to the lookalike Berri-AI/litellm repository.^[0]
5. 5. Release initiation and approval using stolen identities: Under a temporarily relaxed release process, any two engineers could trigger and approve a release. The attacker reportedly used one stolen token to initiate the release and another to approve it after redirecting the deployer. The maintainers noted that the organization-owner token also provided the ability to loosen or remove the restrictions.^[0]
6. 6. Malicious artifact publication and record deletion: LiteLLM 1.107.0 was published to PyPI between 11:39 and 11:40 UTC on October 21. Docker Hub and GHCR images followed at 11:46 UTC. Production and staging run records were deleted between 11:53 and 11:54 UTC.^[0]
7. 7. Conditional downstream execution and credential theft: In an affected Python environment, the bundled startup components could execute when Python started, without a LiteLLM import. The reported stealer collected authentication material and system information, compressed the data, and sent it by HTTP POST to the healthcheck route on litellm.dev. The supplied report does not quantify downstream infections or confirm which credentials were successfully stolen from individual users.^[0]
8. 8. Background backdoor capability: The package also contained a Unix-oriented backdoor launched as a background process to fetch and execute attacker-supplied code every hour. This is a reported payload capability, not evidence of a separately documented follow-on operation against a named downstream victim.^[0]

Disclosure timeline

How it works

Initial access depended on an exposed credential remaining valid. Overwriting the public commit removed the visible configuration from the current repository history but did not revoke the Agent Platform master key. The report describes the attacker later authenticating with that same key; it does not identify a CVE or a software-version-specific flaw as the entry point.^[0]

The first privilege expansion crossed from agent orchestration into source-code administration. The Agent Platform held a GitHub CLI OAuth token so self-hosted cloud agents could file pull requests. The token belonged to the organization's owner and was not sufficiently scoped down, making a credential intended for agent development tasks usable for organization-wide repository access and further credential theft.^[0]

The malicious GitHub Actions workflows were activated by a push event. Short-lived branches were created from recent legitimate commits, a workflow named .github/workflows/cache.yml was added with the innocuous-looking subject 'ci: bump cache config,' and the branches were deleted after use. This explains why the activity could leave little evidence in ordinary branch history even though repository activity records exposed the sequence.^[0]

The workflow collection scope included GitHub tokens and a GitHub App identifier and signing key; Linear, LiteLLM, Together AI, Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian credentials; Playwright storage state; PostgreSQL connection and account information; and Redis connection and authentication details. The report notes that valid Playwright browser state could provide authenticated Linear access without a fresh password or MFA challenge. These are reported collection targets, not confirmation that every listed credential was successfully acquired and used.^[0]

Release compromise combined source substitution with stolen approval identities. The attacker pointed the deployer at Berri-AI/litellm instead of BerriAI/litellm, then satisfied the relaxed two-engineer process using separate stolen tokens. The maintainers' observation that an owner token could also change the approval restrictions limits the protection attributable to the approval workflow alone.^[0]

The downstream payload used Python startup execution rather than relying on an application importing LiteLLM. Its credential-stealing path gathered system information, SSH material, Git and GitLab credentials, environment variables, browser-related authentication material, and tokens for ecosystems including npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, and Cargo. A separate Unix-oriented background backdoor fetched and executed code hourly. Because startup components existed outside the LiteLLM application directory, deleting that directory alone could leave malicious execution components behind.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• Removing a leaked secret from repository content did not end its usefulness: the unrecalled master key remained an entry point months after exposure.^[0]
• The decisive trust-boundary failure was an agent platform holding an organization-owner GitHub token for a narrower pull-request task. Subsequent workflow-based credential theft expanded access into release approval and additional service credentials.^[0]
• Two-person release approval did not provide independent protection once the attacker controlled two engineers' tokens. The stolen owner credential also meant approval-policy integrity itself required investigation.^[0]
• Downstream exposure was not limited to explicit LiteLLM imports, and cleanup was not limited to the LiteLLM application directory. The reported Python startup execution and residual components materially change scoping and eradication requirements.^[0]
• The report explicitly supersedes the earlier theory of token theft from internal deployment logs. It nevertheless leaves chronology discrepancies unresolved, and all incident details in this dossier are supported by a single supplied article rather than independently supplied original investigations.^[0]

Defensive actions

• Identify and stop using LiteLLM 1.107.0 and investigate environments that received the compromised release or its container images.: The report identifies this package version as malicious and documents associated Docker Hub and GHCR publication. Include affected Python environments even when applications never imported LiteLLM, because startup alone could activate the payload.^[0]
• Inspect affected Python environments for malicious startup components outside the LiteLLM application directory; do not treat package-directory removal as complete remediation.: The reported startup files could survive removal of the application files, and the payload included a background backdoor as well as credential theft.^[0]
• Revoke and replace the exposed Agent Platform master key and downstream GitHub credentials, including owner and maintainer OAuth tokens and exposed GitHub App signing material.: The unrevoked master key enabled initial access, the owner token enabled repository-wide access, and additional maintainer tokens enabled release initiation and approval. The workflows also targeted GitHub App credentials.^[0]
• Assess and invalidate other exposed secrets and session material, including inference-provider keys, cloud credentials, database credentials, GitGuardian credentials, and affected Linear browser sessions.: The workflow collection scope extended beyond release tokens. The article specifically describes Playwright browser state capable of authenticated access without a fresh password or MFA challenge, so credential rotation alone may not address all collected authentication material.^[0]
• Remove organization-owner credentials from agent automation and constrain replacement GitHub credentials to the operations and repositories those agents require.: A token configured so agents could file pull requests was insufficiently scoped and associated with an organization owner, allowing compromise of one agent platform to expand into organization-wide repository control.^[0]
• Restore restrictive release approvals, verify the deployer's repository source, and review branch-protection and approval-policy changes made with privileged tokens.: The attacker combined a lookalike release source with two stolen approval identities. The maintainers also stated that the owner token could change the restrictions themselves, so review must include privileged policy changes rather than only whether two approvals were present.^[0]
• Hunt repository activity and workflow records for the named ci-tmp- branches, additions of .github/workflows/cache.yml, the subject 'ci: bump cache config,' and rapid branch or run deletion.: The recovered malicious activity used push-triggered workflows on short-lived branches based on legitimate commits. Branch deletion and removal of run records make ordinary current-branch history an incomplete investigation source.^[0]
• Review Agent Platform access for 69.48.229.143 and outbound traffic for litellm.dev and the two identified webhook.site endpoint identifiers; prioritize destination-specific controls.: These are the reported initial-access and exfiltration indicators. Endpoint-level matching is important for webhook.site because the evidence identifies specific attacker-used endpoints on a shared service, not exclusive attacker ownership of the domain.^[0]