Malicious LiteLLM 1.107.0 Release Turned Developer Environments Into Credential Targets
On October 24, a report detailed how an attacker used an unrevoked LiteLLM Agent Platform master key to reach GitHub credentials, manipulate the project's release process and publish LiteLLM 1.107.0. The package was engineered to run code when Python started, allowing its potential impact to extend beyond applications that actively imported LiteLLM.
The incident began with a configuration file committed to a public LiteLLM repository on May 27, 2026. Although the exposed keys were identified as requiring revocation, the master key was not revoked. On October 10, the attacker used it to access the Agent Platform and extract a GitHub CLI OAuth token used by self-hosted cloud agents. That token was associated with the GitHub organization owner's account and was not narrowly scoped, giving the attacker owner-level access across the organization's repositories.
The attacker then used short-lived branches and temporary workflow files to harvest more credentials while leaving little evidence in the ordinary repository history. The workflows targeted GitHub tokens, a GitHub App signing key, Linear credentials and LiteLLM secrets, and later expanded to credentials for Anthropic, OpenAI, AWS Bedrock, Tavily and GitGuardian. They also collected database, Redis and browser-session information before sending the gathered data to external webhook endpoints.
The release pipeline was altered to use a lookalike repository, after which LiteLLM 1.107.0 was published to PyPI and container images were published to Docker Hub and GHCR on October 21. PyPI later quarantined version 1.107.0, while the affected Docker tags were removed or redirected to verified clean images. The compromise was possible in part because a temporary change allowed any two engineers to trigger and approve a release instead of requiring the usual approval account locked to a physical device.
The package itself created a broader risk than a compromised LiteLLM deployment. Its files were designed to execute automatically when Python started, even if LiteLLM was never imported. One component harvested credentials from developer tools, AI applications, cloud environments and browsers; another ran as a Unix background process that could fetch and execute attacker-supplied code hourly. The malicious startup files were outside the LiteLLM application directory, so deleting only the application files could leave them behind.
Teams should therefore avoid LiteLLM 1.107.0 and the affected container tags identified in the incident, and should not assume that removing the package alone eliminates the compromise. Environments that executed the release need investigation of startup files and credentials exposed to the affected environment. LiteLLM said it was working to revoke tokens associated with its internal systems and vendor platforms; the supplied evidence does not identify a replacement version or a complete consumer remediation procedure.