LiteLLM 1.107.0 was malicious: what organisations need to check

On 21 October 2026, the LiteLLM release pipeline published a malicious version 1.107.0 to PyPI and container registries. Two days later, the project team described the chain of events: a key committed to a public repository, stolen GitHub tokens, a modified release process and the signing of malicious artifacts.

This matters beyond AI teams. LiteLLM may run as a library, a gateway to multiple model providers or part of developer infrastructure. If a malicious artifact was installed on a developer workstation, CI/CD runner or proxy server, cloud secrets, repository tokens, model-provider keys and user sessions may have been within reach.

The priority action: do not treat a package upgrade as complete incident closure. Establish where 1.107.0 was downloaded or executed, preserve evidence, rebuild from trusted artifacts and rotate every credential that could have been available to the process.

What the LiteLLM team confirmed

According to the project’s root-cause analysis, a configuration file containing the master key for an experimental agent platform was committed to a public repository in May 2026. The commit was quickly overwritten, but the key was not successfully revoked. On 10 October, the attacker used it to access the platform API and retrieve a GitHub CLI token belonging to an organisation owner.

That token carried broad authority. The attacker used it to run short-lived workflows that exfiltrated further CI secrets, obtaining tokens for two maintainers. They then changed the private release process to pull code from the lookalike Berri-AI/litellm repository and used the stolen identities to trigger and approve the release.

Seven malicious wheels reached PyPI between 11:39 and 11:40 UTC on 21 October. Docker Hub and GitHub Container Registry images followed minutes later. The project says the artifacts remained available for roughly two hours. Pipeline run records were deleted and the workflow history was overwritten, but audit logs preserved evidence of the actions.

CERT-In says the artifacts contained cook.pth, cook.py and sitecustomize.py. Python startup mechanisms could execute the code without an explicit LiteLLM import. The described collection component targeted browser credentials, SSH and GPG keys, AWS, Azure and Google Cloud secrets, environment variables, CI/CD tokens and credentials used by AI development tools.

Who needs to investigate

Organisations need an urgent check if, on or after 21 October, they:

• installed litellm==1.107.0 from PyPI;
• pulled or ran a LiteLLM image from Docker Hub or GHCR during the incident window;
• cache packages in an internal mirror, CI cache or private container registry;
• built an application image on top of an affected layer;
• started Python in an environment where the malicious files reached site-packages.

The absence of an explicit library import does not rule out exposure. This is a key difference between a conventional vulnerability and a malicious package: preparing the environment and starting the interpreter may have been enough.

An organisational response plan

1. Build an exposure inventory

Search dependency manifests, lockfiles, SBOMs, build logs, package caches, image layers and deployment history. Include developer laptops, ephemeral runners and test environments, not only production. Record installation time and process identity.

2. Preserve evidence before cleanup

Where exposure is plausible, retain EDR, DNS, proxy, CI/CD, container registry, repository and cloud logs. CERT-In recommends isolating suspected hosts and preserving forensic evidence before terminating processes. Hasty file deletion can destroy information required to establish scope.

3. Rebuild instead of trusting in-place cleanup

Recreate containers and runners from images and dependencies with verified provenance. Purge affected artifacts from caches, mirrors and internal registries. Moving a tag does not remove a layer already pulled or an image reused by another build.

4. Rotate secrets from a clean environment

Scope rotation according to what the process could read: GitHub and CI/CD tokens, cloud keys, registry credentials, Vault secrets, LLM provider keys, LiteLLM master_key and salt_key, and where justified browser sessions and SSH/GPG keys. Perform rotation from a trusted host.

5. Hunt for credential use

Review sign-ins, cloud API calls, repository activity, workflow changes, model-key usage and LiteLLM database access. Failure to find a file on a live host does not prove there was no exposure if the environment has already been destroyed.

Governance lesson: deleting a leaked secret does not revoke it

The most consequential event in the LiteLLM analysis happened five months before the malicious release. A key was exposed and the commit was overwritten, but rotation was not completed. This is the difference between removing evidence and removing access.

Organisations should measure not only leaks found by a scanner, but also time to credential revocation, verified completion of rotation and removal of every copy. Branch protection is also insufficient when a stolen owner identity can disable it and approvals belong to other compromised accounts.

A release process should separate authority to change the source, trigger a build, approve production and publish. Each artifact should remain bound to a specific commit. Alerts should cover source-repository changes, rule bypasses, log deletion and force pushes to protected branches.

Source facts and Breachroad conclusions

LiteLLM confirms the dates, stolen tokens, release-process changes, publication of wheels and images, and the roughly two-hour availability window. CERT-In documents version 1.107.0, the malicious startup files, potentially collected credentials and guidance on isolation, rebuilding and rotation.

The response order, separation-of-duties model and secret-management metrics are Breachroad recommendations. Our guides to software supply-chain attacks and secrets management and rotation provide more context. Technical teams and process owners can rehearse incident decisions through our cybersecurity training for organisations, while an IT security audit can validate the real exposure path.

Primary sources: LiteLLM — attack-chain analysis, CERT-In — CIAD-2026-0053, GitHub Advisory Database — GHSA-92x9-889m-jgmw.