# Leaked LiteLLM Master Key Sat Unrevoked for 136 Days, Then Shipped a Malicious 1.107.0 Release > Source: > Published: 2026-10-24 14:04:22+00:00 One secret that was flagged for revocation and never revoked gave an attacker owner-level control of the LiteLLM GitHub organization and a path to publish a malicious release of one of the most widely used open source LLM gateways. LiteLLM disclosed on October 24, 2026 that a master key for its Agent Platform, committed to a public repository on May 27, 2026, was used on October 10 to start a chain that ended with LiteLLM 1.107.0 being published to PyPI, Docker Hub and GHCR on October 21. The release was live on PyPI for roughly an hour and 45 minutes before quarantine, and the container tags stayed poisoned for about two and a half hours. For a package that sits between applications and every upstream model provider they call, that window matters. On May 27, 2026, a configuration file committed to the public LiteLLM-Labs/lite-harness repository contained the master key for a deployment of the LiteLLM Agent Platform, an open source tool LiteLLM uses to orchestrate agents. The team spotted the mistake, force-pushed over the commit and marked the exposed keys for revocation. The master key was never actually revoked. Force-pushing removes a commit from branch history, not from every clone, mirror or scraper that already captured it. The key stayed valid for 136 days until the attacker used it. On October 10, 2026, an attacker operating from 69.48.229[.]143 authenticated to the Agent Platform with the leaked key and pulled a GitHub CLI OAuth token the service used so self-hosted cloud agents could open pull requests. That token was not scoped down and belonged to the GitHub organization owner's account. It gave the attacker owner-level access to every repository in the organization. ⚠️ **The core failure** — An automation credential whose only job was filing pull requests carried full organization owner rights. Once the Agent Platform fell, there was no permission boundary left between the attacker and the release process. Between 10:11 and 10:12 p.m. UTC on October 10, the attacker pushed commits to throwaway branches on the internal BerriAI/litellm and BerriAI/litellm-auto repositories. Socket recovered two malicious commits, one on October 10 at 10:11:45 p.m. UTC and a second on October 12. Each followed the same pattern: Socket noted that neither commit landed on a branch that still exists, which is why ordinary repository history shows almost nothing. The evidence lived in activity logs. The October 10 workflow harvested GitHub CLI OAuth tokens for two engineers with maintainer privileges, plus keys for the Linear workspace, a LiteLLM deployment, Together AI, and a GitHub App identifier and signing key. The October 12 run widened collection to API keys for Anthropic, OpenAI, AWS Bedrock, Tavily and the GitGuardian secret-scanning tenant, along with Playwright storage state, PostgreSQL connection strings and credentials, and Redis endpoint, port and password. Data went to two webhook[.]site endpoints. LiteLLM's normal release process requires an authorized engineer to start a build and a special account tied to a physical device in the office to approve it. That week the control had been relaxed to allow any two engineers to trigger and approve releases, to support a push for more frequent releases and bugfix backports. The attacker had exactly two maintainer tokens. LiteLLM pointed out that the attacker already held an owner token and could have disabled the two-person rule outright. The team suspects the attacker chose not to in order to avoid detection. Using the relaxed control as designed produced a release that looked procedurally normal. PyPI quarantined the release and LiteLLM repointed the affected Docker Hub tags to verified clean images. LiteLLM says it is revoking every token associated with every internal system and vendor platform. The disclosure does not detail the behavior of the code inside 1.107.0, so the full downstream impact on environments that installed it is not yet public. **RedEye assessment** — Three separate controls failed in sequence: secret revocation after a known leak, least privilege on an automation token, and release approval that had been loosened days earlier. Each one alone would likely have stopped this chain. AI gateways concentrate provider keys for an entire organization, which makes the secrets they hold and the pipelines that build them high-value targets. RedEye Security can assess your exposure to this incident and review how your CI/CD and AI tooling credentials are scoped. *Originally published on [RedEye Threat Intelligence](https://threat-intelligence.redeyesecurity.com/blog/litellm-master-key-leak-malicious-release-2026).*