LiteLLM compromise: why removing the affected package is not enough

What happened?

Microsoft reports that a compromised version of LiteLLM, numbered 1.107.0, was published on 21 October 2026 through the Python Package Index and official container images. LiteLLM connects applications to AI model providers, but it can also be installed on developers’ computers, testing systems and automated software-building services.

According to LiteLLM’s maintainers, attackers used stolen GitHub credentials to change the release process so it drew from a lookalike repository. Another developer account’s credential was used to approve production release. Microsoft has not independently established how those credentials were obtained.

Why this attack is different

The malicious release placed files where Python, the programming language used by LiteLLM, could run them automatically during startup. An application did not have to use LiteLLM directly. In one Windows example, installing an unrelated software dependency triggered the credential collector.

This also complicates clean-up. The malicious startup files were placed outside LiteLLM’s usual application folder, so deleting that folder could leave the attack mechanism intact. Microsoft says recovery must cover the affected Python environment, any processes still running and credentials available to the compromised account.

A separate component aimed at Unix-based systems could download and run further code. That capability was present, but researchers did not confirm that additional code had actually been retrieved or executed.

Why small businesses should care

The concern extends beyond an AI application failing. A LiteLLM gateway may hold API keys, which allow applications to access AI services, along with database connection details and cloud access credentials. Developer computers and build systems can also contain credentials for other business services.

The collector targeted a broad range of information, including cloud credentials, developer-tool settings, browser data, private keys and secrets stored in system settings. It also attempted to read selected LiteLLM database records. Information collected was encrypted before the malware attempted to send it to an attacker-controlled destination.

However, a target listed in the malicious code does not prove that information was successfully accessed or stolen. Microsoft observed behaviour consistent with the collector on Windows and macOS, but each business still needs to establish what happened in its own environment.

What to do next

Ask your IT provider or development team whether LiteLLM 1.107.0 was installed, stored in a package cache or internal software mirror, or included in a container image. Checks should also cover dependency lock files and software build outputs, rather than focusing only on live AI services.

Do not launch Python or its package installer, pip, inside a suspect environment to check the version. That apparently routine action could activate the malicious files. Have your technical team investigate from outside the affected environment and contain identified copies.

Treat package removal as only one part of recovery. Ask your responders to assess remaining startup files, running processes and accessible credentials, then determine which credentials need replacing or revoking. Microsoft’s report provides detection information and investigation indicators to support that work.

For container deployments, ask the team to identify the exact image content using its digest, not just its release tag. Tags can change; a digest identifies a particular image.