Microsoft Threat Intelligence has published a detailed breakdown of the compromised LiteLLM 1.107.0 release, and its central warning is uncomfortable for any team running Python: the malicious code did not wait for an application to use LiteLLM. Starting Python in an affected environment could be enough to run it.
LiteLLM is widely used as a gateway between applications and model providers, a position that can give it access to model-provider API keys, database connection strings, workload identities, routing configuration and tenant policy data. Microsoft said the compromised release was published to the Python Package Index on October 21, 2026, and distributed through official container images, widening exposure to developer workstations, build agents, test systems and containers as well as gateway hosts.
According to LiteLLM's maintainers, as reported by Microsoft, stolen developer GitHub credentials were used to alter the release workflow and redirect it to a lookalike repository, Berri-AI/litellm, rather than the legitimate BerriAI/litellm repository. A credential associated with another developer account was then used to satisfy a production approval step. Microsoft said it has not independently determined how the attacker first accessed the upstream environment or obtained those credentials.
The compromised wheel packaged three files, cook.pth, cook.py and sitecustomize.py, outside the normal LiteLLM application directory. Python processes executable lines in .pth files and imports sitecustomize during normal site initialization, so the first file loaded a credential collector identified as PRIVCOLLECT, while the second provided a separate Unix-oriented path. That placement also means removing only the LiteLLM application files could leave the malicious startup components behind.
Microsoft said the collector was designed to gather authentication material across developer and AI tools, source-control and package-manager configuration, AWS, Azure and Google Cloud credentials, Kubernetes and Docker configuration, browser data, SSH and other private-key material, process environment variables and selected records from the LiteLLM proxy database. Collected data was serialized, encrypted with AES-256-CBC, its key wrapped with a 4,096-bit RSA public key, and an upload was attempted to an attacker-controlled endpoint. A target appearing in the code, Microsoft stressed, does not establish that it was successfully accessed.
The Unix loader was designed to read a GitHub-hosted pointer file, retrieve additional Python code from a server it named, and execute it without a content-signature check. When researchers examined the pointer it was empty, and Microsoft said second-stage retrieval and execution were not confirmed, but the mechanism remained capable of being re-armed without publishing another compromised package.
Endpoint observations on Windows and macOS matched the collector's discovery, encryption and outbound-connection behavior, Microsoft said, including one Windows case in which a routine Python invocation to install an unrelated dependency activated it. For that reason, investigators should not run Python or pip inside a suspect environment to check whether the package is present.
Microsoft's recovery guidance goes well beyond uninstalling a package. Organizations that installed, mirrored or built images with LiteLLM 1.107.0 should find every copy in environments, caches, internal mirrors, lock files and container images, isolate affected systems, rebuild from verified artifacts, confirm the three startup files are gone, and rotate reachable credentials from a known-clean machine. Presence of the package alone is not proof of compromise; file hashes, process ancestry, staging artifacts, network destinations and later identity use should be correlated before a verdict is declared.