## Accidental Exposure Ignites Supply Chain Attack **LiteLLM** disclosed on Friday that an **Agent Platform** master key, accidentally committed to a public **GitHub** repository in late May 2026, was ultimately exploited by a threat actor. This compromise enabled the attacker to publish a malicious version of the widely used Python package. "On May 27, 2026, a configuration file was committed to the public **LiteLLM-Labs/lite-harness** repository which inadvertently contained the master key to a deployment of the **LiteLLM Agent Platform**, an open source tool we use for orchestrating agents," stated **LiteLLM's** Oliver Jensen and Mateo Wang. They further explained, "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." ## Unrevoked Key Grants Broad Access **LiteLLM** reported that an unknown attacker, operating from the IP address "69.48.229[.]143," exploited this unrevoked master key on October 10, 2026. This allowed them to access the **Agent Platform** and extract a **GitHub CLI OAuth** token. The token was configured to enable self-hosted cloud agents to file pull requests to **GitHub** repositories. Critically, the developers of the open-source large language model (LLM) gateway noted that the token was "not scoped down" and was associated with their **GitHub** organization owner's account. This provided the attacker with owner-level access to all repositories across the organization, facilitating further credential exfiltration. ## Attack Timeline and Escalation The threat actor executed a series of actions after gaining initial access: * **October 10, 2026, 10:11 - 10:12 p.m. UTC:** The attacker made commits to throwaway branches on internal repositories (**BerriAI/litellm** and **BerriAI/litellm-auto**). These commits were designed to run workflows that acquired **GitHub CLI OAuth** tokens associated with two engineers holding maintainer privileges, exfiltrating them via an attacker-controlled webhook.site endpoint. The runs were deleted minutes later. * **October 21, 2026, 10:08 - 11:08 a.m. UTC:** Branch protection was overridden, and the release pipeline was altered to point to a lookalike repository, "**Berri-AI/litellm**," instead of the legitimate "**BerriAI/litellm**." * **October 21, 2026, 11:39 - 11:40 a.m. UTC:** **LiteLLM** version 1.107.0 was published to **PyPI**. * **October 21, 2026, 11:46 a.m. UTC:** **Docker Hub** and **GHCR** images were published. * **October 21, 2026, 11:53 - 11:54 a.m. UTC:** Production and staging run records were deleted. * **October 21, 2026, 12:06 p.m. UTC:** **Upwind** researcher Lidor Machluf reported the supply chain attack. * **October 21, 2026, 1:23 p.m. UTC:** **PyPI** quarantined **LiteLLM** version 1.107.0. * **October 21, 2025, 2:20 p.m. UTC:** **Docker Hub** tags v1.107.0, latest, main-latest, and main-stable were removed or repointed to verified clean images.  **LiteLLM** explained that their typical release process requires authorization from an engineer and approval from a special account locked to a physical device. However, this restriction was temporarily relaxed to accommodate more frequent releases, allowing any two engineers to trigger and approve a release. The threat actor exploited this relaxed policy, using one stolen token to trigger the release (after redirecting the deployer to their malicious repository) and another to approve it. The maintainers noted that the attacker, possessing an organization owner's token, could have easily loosened or removed these restrictions themselves. It is suspected this was avoided to evade detection. In response, **LiteLLM** is revoking all tokens associated with internal systems and vendor platforms, as the workflows were designed to identify and exfiltrate additional keys and tokens, particularly upstream inference API tokens. ## Malicious Workflows and Credential Harvesting **Socket**, an application security firm, published its own investigation into the malicious workflows, recovering two commits that added a workflow at ".github/workflows/cache.yml." The first commit was made on October 10, 2026, at 10:11:45 p.m. UTC, followed by a second on October 12. **Socket** security researcher Karlo Zanki detailed that these commits were pushed to short-lived branches (e.g., ci-tmp-a351cc, ci-tmp-4d8517) that were created, used, and deleted within minutes, leaving minimal traces in the repository's history. Both workflows, as highlighted by **LiteLLM**, were configured to harvest various sensitive credentials: * **GitHub** tokens and **API** keys for the organization's **Linear** workspace, **LiteLLM** deployment, and **Together AI**. * Identifier and signing key of a **GitHub App**. * The October 12 run extended collection to **API** keys for **Anthropic**, **OpenAI**, **AWS Bedrock**, **Tavily**, and **GitGuardian's** secret-scanning tenant. * **Playwright** storage state. * **PostgreSQL** database information (connection string, account name, password). * **Redis** endpoint address, port, and authentication password. The collected data was exfiltrated to two **webhook[.]site** endpoints: `webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37` and `webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1`. Zanki emphasized the severity of the exfiltrated credentials: "A **GitHub** token and a **GitHub App** private key are credentials for the platform hosting the repository, not for a third-party service. **GITGUARDIAN_API_KEY** is a credential for the secret-scanning platform itself, which gives an attacker visibility into, and potentially control over, the alerts that would surface this activity. **E2E_LINEAR_STORAGE_STATE_B64** is serialized browser session state used by **Playwright** for end-to-end tests; a valid storage state permits authenticated access to the associated **Linear** account without a password and without satisfying multi-factor authentication." These findings ultimately disproved **LiteLLM's** initial hypothesis that the **GitHub CLI OAuth** tokens were stolen from internal deployment logs. Jensen acknowledged, "The investigation was a process in which we continually learned additional information, meaning some of our assumptions and beliefs were later proven to be inaccurate or incomplete." ## Malicious Package Functionality Reports indicate that files bundled with **LiteLLM** version 1.107.0 are engineered to execute automatically when Python starts, even if an application does not explicitly import **LiteLLM**. The malware features two execution paths, designed for credential stealing and establishing a persistent Python backdoor.