"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," Oliver Jensen and Mateo Wang said.
How a leaked master key opened the door
LiteLLM's account establishes the initial error with precision: a configuration file containing a master key was published to the public LiteLLM-Labs/lite-harness repository on May 27, 2026. The project says the commit was quickly force-pushed over and exposed keys were identified as needing revocation — except for the master key, which was not revoked. According to LiteLLM, an unknown attacker operating from 69.48.229[.]143 used that unrevoked key on October 10, 2026 to access the Agent Platform and extract a GitHub CLI OAuth token the service held.
Token theft, throwaway branches, and short-lived workflows
Once the attacker had the GitHub CLI OAuth token — which LiteLLM says was "not scoped down" and was associated with the organization's owner account — they gained owner-level access across the organization's repositories. On October 10, 2026, between 10:11 and 10:12 p.m. UTC, the actor committed into throwaway branches on internal repositories (BerriAI/litellm and BerriAI/litellm-auto) to run workflows designed to harvest tokens for two engineers with maintainer privileges and send them to an attacker-controlled webhook[.]site endpoint. Those runs were deleted minutes later.
Socket's analysis recovered two malicious commits that added a workflow at .github/workflows/cache.yml: the first on October 10, 2026 at 10:11:45 p.m. UTC and a second commit on October 12. Both were pushed to short-lived branches named ci-tmp-, created from recent legitimate commits, used to trigger the workflows (configured "on: [push]"), and deleted within minutes — leaving little trace in ordinary repository history.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildRelease pipeline hijack and the publication of 1.107.0
The attacker moved from token harvesting to pipeline takeover. On October 21, 2026, between 10:08 and 11:08 a.m. UTC, branch protection was overridden and the release pipeline was altered so its source pointed to the lookalike repository "Berri-AI/litellm" rather than "BerriAI/litellm." LiteLLM reports that the malicious LiteLLM version 1.107.0 was published to PyPI between 11:39 and 11:40 a.m. UTC on October 21, 2026. Docker Hub and GHCR images were pushed at 11:46 a.m. UTC. Production and staging run records were deleted between 11:53 and 11:54 a.m. UTC.
Upwind researcher Lidor Machluf reported the supply chain attack at 12:06 p.m. UTC that day; PyPI quarantined LiteLLM 1.107.0 at 1:23 p.m. UTC. The timeline also records that, on 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 says that in normal operation releases require initiation by an authorized engineer and approval by a special account locked to a physical device in their office, but that restriction had been relaxed earlier in the week to allow any two engineers to trigger and approve releases. The project says the attacker used one harvested token to trigger the release and another to approve it — and that an organization owner token would have permitted loosening the restriction entirely, though LiteLLM suspects the actor did not do so to avoid detection.
What the malicious 1.107.0 package did when it ran
Multiple analyses show the files bundled with LiteLLM 1.107.0 were engineered to execute automatically when Python started, even if an application never imported LiteLLM. The malicious bundle contained two principal components: a credential-harvesting module targeting authentication material across developer tools, AI applications, cloud environments and web browsers; and a Unix-oriented backdoor that launched as a background process and fetched and executed arbitrary code supplied by the attacker every hour.
The stealer collected system information, SSH files, Git and GitLab credentials and tokens, environment variables, and tokens for a wide range of package ecosystems — npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems, and Cargo. Collected data were compressed and posted to litellm[.]dev/healthcheck; the domain was registered on October 13, 2026. Microsoft Security Research noted that because malicious startup files resided outside the LiteLLM application directory, removing only application files could leave the malicious startup components behind.
Socket's findings: what was exfiltrated and where
Socket and LiteLLM describe the workflows as explicitly designed to harvest GitHub tokens and API keys for multiple services. Initial exfiltration targeted GitHub, the organization's Linear workspace, the LiteLLM deployment itself, Together AI, and a GitHub App identifier and signing key. The October 12 workflow extended the sweep to API keys for Anthropic, OpenAI, AWS Bedrock, Tavily, and GitGuardian's secret-scanning tenant; it also captured Playwright storage state, PostgreSQL connection information, and Redis credentials.
Collected data were exfiltrated to two webhook[.]site endpoints: webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 and webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1. Socket's Karlo Zanki highlighted the operational implications: a GITGUARDIAN_API_KEY can give an attacker visibility into — and potential control over — secret-scanning alerts, while E2E_LINEAR_STORAGE_STATE_B64 is serialized Playwright browser session state that permits authenticated access to a Linear account without password or MFA.
What this means for developers, platform operators, and open-source maintainers
- Developers: the malicious package could execute simply by starting Python, so environments and CI runners that run Python without strict isolation are at elevated risk; Microsoft Security Research warns that removing only application files may not remove the startup components.
- Platform operators and vendor teams: the attacker exploited an unrevoked master key and an unscoped GitHub CLI OAuth token associated with an organization owner; LiteLLM says it is working to revoke every token associated with internal systems and vendor platforms. The incident underlines the danger of tokens that are not scoped down and of relaxed release gating.
- Open-source maintainers: short-lived branches and workflows can be used to leave minimal forensic traces; Socket's recovery shows attackers can create throwaway branches from legitimate commits, push malicious workflows, trigger them, and delete branches within minutes.
The LiteLLM incident maps a compact, multi-step supply-chain attack: a leaked master key, long-dormant access that was activated in October, short-lived repository workflows to harvest credentials, a pipeline redirection to a lookalike repository, and a malicious package that executes on Python startup and exfiltrates broad credential material. The public timeline — from the May 27, 2026 configuration commit to PyPI quarantining 1.107.0 on October 21, 2026 — leaves clear signals for organizations to audit unrevoked keys, restrict token scopes, and re-examine release approval practices.