← All articles

LiteLLM 1.107.0 compromise spread credential malware

LiteLLM 1.107.0 compromise spread credential malware

LiteLLM 1.107.0 was published with credential-stealing malware after an unknown attacker turned a previously exposed master key into control over the project's GitHub repositories and release process. The compromised Python package reached the Python Package Index (PyPI), a service used to distribute Python software, as well as Docker Hub and the GitHub Container Registry (GHCR) on October 21, 2026.

The incident began on May 27, 2026, when a configuration file committed to the public LiteLLM-Labs/lite-harness repository exposed the master key for a LiteLLM Agent Platform deployment. The Agent Platform is an open-source tool the project used to coordinate software agents. LiteLLM said the mistake was quickly noticed and the public commit was overwritten with a force push. The exposed credentials were identified for revocation, but the master key itself was not revoked.

On October 10, an unknown attacker connecting from 69.48.229[.]143 used that key to enter the Agent Platform. From there, the attacker obtained a GitHub command-line interface OAuth token, a digital credential that lets an application act through a GitHub account. The service used this token so self-hosted cloud agents could submit pull requests. LiteLLM said the token had not been limited to a narrow set of permissions and belonged to an owner of its GitHub organisation, giving the attacker owner-level access across its repositories.

Between 10:11 and 10:12 p.m. UTC that day, the attacker created temporary branches in BerriAI/litellm and BerriAI/litellm-auto. Malicious GitHub workflows, which are automated tasks run inside a repository, were used to obtain OAuth tokens belonging to two engineers with maintainer access. The credentials were sent to an attacker-controlled webhook[.]site address, and the workflow runs were deleted minutes later.

Socket later recovered two malicious commits that placed a file at .github/workflows/cache.yml. One was created at 10:11:45 p.m. UTC on October 10, and another followed on October 12. Each used a short-lived branch based on a recent legitimate commit, added the workflow with the innocuous-looking subject “ci: bump cache config,” ran whenever code or a tag was pushed, and then deleted the branch. The branch names were ci-tmp-a351cc and ci-tmp-4d8517, leaving little visible in the repositories' ordinary history.

The workflows collected GitHub credentials, a GitHub App identifier and signing key, and access material for Linear, the LiteLLM deployment and Together AI. The October 12 version expanded the collection to application programming interface (API) credentials for Anthropic, OpenAI, AWS Bedrock, Tavily and GitGuardian. It also targeted Playwright browser session data, connection details for the open-source database, and Redis addresses, ports and passwords. Socket noted that a valid Playwright session could provide access to the associated Linear account without entering a password or completing multi-factor authentication. A GitGuardian credential could expose, and potentially allow control over, alerts from the secret-scanning service. The two destinations were webhook[.]site/65a42464-3cfa-4b02-a18c-17a6d7b86f37 and webhook[.]site/4da03473-a3e7-4dc2-a087-9c564b4208e1.

On October 21, between 10:08 and 11:08 a.m. UTC, the attacker bypassed branch protection, the GitHub controls intended to restrict sensitive code changes, and changed the release pipeline to use the lookalike Berri-AI/litellm repository instead of BerriAI/litellm. LiteLLM said releases normally needed initiation by an authorised engineer and approval from a special account tied to a physical device in its office. Earlier that week, the rule had temporarily been relaxed so any two engineers could trigger and approve releases. The attacker used one stolen token to start the release and another to approve it. Because an organisation owner's token was already compromised, LiteLLM said the attacker could likely have removed the restriction entirely, but may have avoided doing so to reduce the chance of detection.

LiteLLM 1.107.0 was published to PyPI between 11:39 and 11:40 a.m. UTC. Docker Hub and GHCR images followed at 11:46 a.m., and production and staging run records were deleted between 11:53 and 11:54 a.m. Upwind reported the supply-chain attack at 12:06 p.m., and PyPI quarantined the affected version at 1:23 p.m. LiteLLM's timeline says the Docker Hub tags v1.107.0, latest, main-latest and main-stable were removed or redirected to verified clean images at 2:20 p.m. UTC, although that line gives October 21, 2025, unlike the surrounding events dated 2026.

Multiple investigations found that the malicious files could run whenever Python started, even if an application never imported LiteLLM. One component harvested credentials from developer tools, AI services, cloud environments and web browsers. It also collected system details, SSH files, Git and GitLab credentials, environment variables, and tokens associated with npm, PyPI, pip, Yarn, Maven, Gradle, Composer, RubyGems and Cargo. The stolen data was compressed and sent by an HTTP POST request to litellm[.]dev/healthcheck, a domain registered on October 13, 2026.

A second component installed a Unix-oriented backdoor, meaning a hidden method for remotely running commands, as a background process. It contacted the attacker's infrastructure every hour to retrieve and execute arbitrary code. Microsoft Security Research warned that malicious Python startup files were placed outside the LiteLLM application directory, so deleting only the application could leave those components behind.

LiteLLM said it was revoking tokens connected to its internal systems and vendor platforms. Its investigation also rejected an earlier theory that the GitHub OAuth tokens had been taken from internal deployment logs. For website operators and IT teams, the case shows why software dependencies, build accounts and stored service credentials must all be considered when responding to a compromised package. For organisations reviewing that wider exposure, AEU-I provides security-first IT, infrastructure and consulting.

Also available in: DeutschItalianoShqip