deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Unrevoked LiteLLM master key enabled malicious 1.107.0 release on PyPI and Docker Hub

A LiteLLM master key leaked in May 2026 and left valid for 136 days let an attacker take owner-level control of the BerriAI GitHub org and publish a malicious 1.107.0 release to PyPI, Docker Hub and GHCR.

Unrevoked LiteLLM master key enabled malicious 1.107.0 release on PyPI and Docker Hub

LiteLLM disclosed on October 24, 2026 that a malicious build of version 1.107.0 was shipped through the project's official channels on October 21, after an attacker spent eleven days holding owner-level access to the BerriAI GitHub organization. According to an analysis by RedEye Threat Intelligence republished on dev.to, the entry point was a master key for LiteLLM's Agent Platform that leaked publicly in May 2026, was spotted — and never revoked.

A key that was caught but not revoked

On May 27, 2026, a configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key for an Agent Platform deployment, the tool LiteLLM uses to orchestrate agents. The team noticed the mistake, force-pushed the commit out of branch history and flagged the exposed credentials for revocation, but the master key itself was never invalidated. As RedEye points out, force-pushing hides a commit from a branch's history, not from the clones, mirrors and scrapers that had already copied it. The key stayed valid for 136 days.

From leaked key to organization owner

On October 10, 2026, an attacker connecting from 69.48.229[.]143 used that key to authenticate to the Agent Platform and pulled out a GitHub CLI OAuth token the service employed so self-hosted agents could open pull requests. The token was not scoped down and belonged to the GitHub organization owner's account, giving the attacker owner-level rights across every BerriAI repository. RedEye identifies this as the central failure: an automation credential whose only job was filing pull requests carried full organization owner privileges, leaving no permission boundary between the intruder and the release process.

Ghost branches harvested credentials

Between 10:11 and 10:12 p.m. UTC on October 10, the attacker pushed commits to short-lived branches — observed names ci-tmp-a351cc and ci-tmp-4d8517 — on the internal BerriAI/litellm and BerriAI/litellm-auto repositories. Each commit added a workflow file at .github/workflows/cache.yml under a routine-sounding message, "ci: bump cache config", which executed immediately on push. The branches, and shortly afterwards the workflow runs, were deleted, leaving almost nothing in ordinary repository history; RedEye reports that security firm Socket recovered the two commits from activity logs.

The October 10 workflow harvested GitHub CLI OAuth tokens belonging to two engineers with maintainer privileges, plus credentials for a Linear workspace, a LiteLLM deployment, Together AI, and a GitHub App identifier and signing key. A second run on October 12 widened the collection to API keys for Anthropic, OpenAI, AWS Bedrock, Tavily and a GitGuardian secret-scanning tenant, along with Playwright storage state, PostgreSQL connection strings and credentials, and Redis endpoint, port and password details. The data was exfiltrated to two webhook.site endpoints.

Hijacking the release pipeline

LiteLLM's normal release process requires an authorized engineer to start a build and a dedicated account tied to a physical device in the office to approve it. Per the disclosure, that requirement had been relaxed that same week to allow any two engineers to trigger and approve releases, in support of faster releases and bugfix backports — and the attacker happened to hold exactly two maintainer tokens.

Between 10:08 and 11:08 a.m. UTC on October 21, the attacker overrode branch protection and repointed the release pipeline's source from BerriAI/litellm to the near-identical Berri-Ai/litellm. At 11:39, LiteLLM 1.107.0 was published to PyPI, triggered with one stolen token and approved with the other; Docker Hub and GHCR images followed at 11:46, and production and staging run records were deleted at 11:53. LiteLLM noted that the attacker, already holding an owner token, could have switched off the two-person rule outright but presumably left it in place so the release would appear procedurally ordinary.

Upwind researcher Lidor Machluf reported the attack at 12:06 p.m. UTC. PyPI quarantined 1.107.0 at 1:23 p.m., roughly an hour and 45 minutes after publication, and at 2:20 p.m. the Docker Hub tags v1.107.0, latest, main-latest and main-stable were removed or repointed to verified clean images, about two and a half hours after the poisoned builds appeared.

Remediation and open questions

Beyond the PyPI quarantine and container fixes, LiteLLM says it is revoking every token associated with its internal systems and vendor platforms. The disclosure does not describe what the code inside 1.107.0 actually did, so the downstream impact on organizations that installed the release or pulled the affected tags — and on anyone whose inference keys pass through a LiteLLM gateway — remains unknown.

Why it matters

RedEye counts three independent controls failing in sequence, any one of which would likely have broken the chain: revocation after a known leak, least privilege on an automation token, and a release approval rule loosened only days earlier. The incident also shows why AI gateways are attractive targets: they concentrate provider API keys for an entire organization, making both the secrets they hold and the pipelines that build them high-value assets. For teams running LiteLLM, the immediate priorities are checking whether 1.107.0 or the affected container tags were pulled on October 21, and rotating any keys that traversed the gateway.

  • #supply-chain
  • #security
  • #open-source
  • #pypi
  • #github-actions
  • #litellm

Related posts