LiteLLM — Supply Chain Compromise via Python Startup Hooks in Version 1.107.0

Publication date: October 23, 2026
Category: Supply Chain Attacks / Incident Response

Introduction

On October 21, 2026, dependency maintainers and security analysts identified a severe software supply chain compromise affecting the LiteLLM 1.107.0 release. This malicious package was published to the official Python Package Index (PyPI) and distributed through official container images. Investigations conducted by Microsoft Security revealed that threat actors compromised a developer’s credentials to redirect the release workflow toward a lookalike repository (Berri-AI/litellm), subsequently using another account to approve the production deployment. Unlike traditional library-level attacks, the compromised package did not require applications to explicitly import LiteLLM; merely starting the Python interpreter in an affected environment was sufficient to trigger the malicious payload and compromise critical authentication assets.

What is the Affected Component and Incident? (General Analysis)

LiteLLM is a widely deployed gateway operating between applications and multiple Large Language Model (LLM) providers. Due to its architectural position, it manages model-provider API keys, database connection strings, workload identities, routing configurations, and tenant policy data. Its adoption spans beyond dedicated gateway servers to developer workstations, continuous integration and deployment (CI/CD) agents, test systems, and containerized environments, significantly expanding the attack surface.

Because this incident does not currently possess an officially assigned CVE identifier in the NVD database at the time of writing, the risk is evaluated under a reasoned estimation of Critical severity (CVSS v3.1: 9.8 / Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), conceptually classified under CWE-506 (Embedded Malicious Code) and CWE-434 (Unrestricted Upload of File with Dangerous Type) adapted to deployment pipeline tampering.

How Does It Work? (Technical Analysis)

Forensic analysis of the compromised wheels uncovered multiple automated execution paths during Python environment startup, split into two primary mechanisms designed for data harvesting and remote persistence.

• Initial Infection Flow and Automatic Execution: The compromised package bundled three critical components placed outside the application directory: cook.pth, cook.py, and sitecustomize.py under litellm-1.107.0.data/purelib/. During installation, these files were relocated into the Python environment’s library directory. The cook.pth file contained a single executable line (import cook), which immediately loaded cook.py. This script utilized Base64 decoding and zlib decompression to extract and execute an in-memory malicious program self-identified as PRIVCOLLECT, running inside a daemon thread.

• Duplicate Suppression and Credential Collection: Prior to starting collection, the thread checked the inherited PRIVCOLLECT_ACTIVE environment variable. If absent, it set the flag to prevent duplicate collection in descendant processes and proceeded to execute sequential extraction modules. Targets included developer tools and AI assistants (IDE configuration files and VS Code extensions), source control repositories, cloud credentials (AWS, Azure CLI, Google Cloud, Kubernetes service account files, and instance metadata), web browser histories (Chromium and Firefox), additional environment variables via Linux procfs, private keys (SSH, GPG, TLS), and specific LiteLLM proxy tables via Prisma queries constrained by strict row limits.

• Encryption, Exfiltration, and Unix-Oriented Loader: Collected data was serialized into JSON, encrypted using a randomly generated AES-256-CBC key (with a dedicated initialization vector), and wrapped using a 4,096-bit RSA public key via OAEP cryptography. The payload packed these artifacts into a gzip-compressed tar archive and issued an HTTP POST request to the control endpoint hxxp://www[.]litellm[.]dev/healthcheck. On Unix-based systems, sitecustomize.py also implemented a secondary loader protected by mutual exclusion (/tmp/remote_code_loader.lock) that periodically queried a GitHub-hosted pointer (domain.txt) to retrieve and execute additional remote Python code from /codepy, functioning as a re-armable execution mechanism.

Affected Systems / Environments

The incident impacted any environment where the specific supply chain release was installed or derived container images were deployed.

Mitigation and Detection

Remediation

Achieving effective recovery requires more than simply removing the package or release tag from the affected environment. Organizations must execute a strict protocol:

1. Environment Isolation: Stop running Python processes and prevent automated restarts. Do not execute commands like python or pip within suspicious environments to avoid triggering collection.
2. Deep Cleanup: Verify and ensure the complete removal of cook.pth, cook.py, and sitecustomize.py from system library paths. Rebuilding artifacts from verified sources is strongly recommended.
3. Comprehensive Credential Rotation: Immediately rotate all model-provider keys, cloud credentials, CI/CD secrets, source-control tokens, SSH/GPG keys, and browser sessions accessible by the compromised identity from a known-clean machine. Explicitly revoke active sessions on platforms such as Microsoft Entra ID.
4. Dependency Hardening: Utilize hash-pinned lock files, verify image provenance via immutable digests, and restrict unnecessary outbound network access across gateways and developer stations.

Detection

Defensive security teams can leverage detection rules for Microsoft Defender for Endpoint and Advanced Hunting queries:

// KQL query to detect connections to the associated exfiltration domain
DeviceNetworkEvents
| extend UrlForParsing = iff(RemoteUrl contains "://", RemoteUrl, strcat("http://", RemoteUrl))
| extend RemoteHost = trim_end(@"\.", tolower(tostring(parse_url(UrlForParsing).Host)))
| where RemoteHost in ("www.litellm.dev", "litellm.dev")
| project Timestamp, DeviceId, DeviceName, ActionType, RemoteUrl, RemoteIP, RemotePort, InitiatingProcessFileName

Defensive Intelligence Note: The presence of startup files (cook.pth, cook.py, sitecustomize.py) or OpenSSL encryption activity utilizing temporary staging paths prefixed with .pc_e_ during Python processes represent unequivocal indicators of exposure requiring immediate forensic investigation.

Wrapping Up

The LiteLLM 1.107.0 supply chain compromise illustrates how threat actors continue diversifying attack vectors beyond simple functional code insertion in libraries, leveraging native interpreter initialization mechanisms such as Python startup hooks (.pth) to achieve code execution without explicit application intervention. Rapid telemetry detection and coordinated response underscore the vital importance of implementing strict dependency management controls, rigorous continuous integration (CI/CD) pipeline audits, and strict privilege segmentation in artificial intelligence environments.

References

• Microsoft Security. (2026). Inside the LiteLLM 1.107.0 supply chain compromise: Credential theft through Python startup hooks. Microsoft Security Blog. Retrieved from https://www.microsoft.com/en-us/security/blog/?p=150238
• LiteLLM. (2026). Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised.
• Python Software Foundation. Site-specific configuration hook documentation.