LiteLLM 1.107.0 compromise injects credential stealer via build pipeline

On October 21, 2026, security researchers identified that LiteLLM version 1.107.0, published on the Python Package Index (PyPI), contained a credential stealer and a remote code execution backdoor. The compromised package affected Linux, macOS, and Windows environments by injecting malicious files directly into the Python site-packages directory during installation. PyPI has since removed the release, but the incident highlights significant risks in software supply chain integrity.

What happened

The attack targeted the build process of LiteLLM, a popular library for integrating large language models. When developers installed version 1.107.0 using pip, three specific files were placed in their site-packages folder: cook.pth, cook.py, and sitecustomize.py. Unlike typical malware that requires explicit import statements to run, these files executed automatically whenever any Python process started on the host machine. This meant that even applications not directly using LiteLLM could trigger the malicious code if they shared the same Python environment.

The upstream source code repository on GitHub did not contain these malicious files. Forensic analysis revealed that the source distribution (sdist) for version 1.107.0 included a modified pyproject.toml file with an injected line: data = "cook". This instruction directed the build tool, maturin, to copy a hidden cook/ folder into the final wheel package. The sdist itself omitted the cook/ folder, making the injection visible only in the compiled binary wheels distributed via PyPI. Versions 1.106.2, 1.107.0rc1, and 1.107.0rc2 were confirmed to be clean, as were the companion packages litellm-proxy-extras and litellm-enterprise.

How it works

The malicious payload operated through two primary mechanisms triggered by Python’s startup behavior. First, the cook.pth file contained the command import cook. Python automatically executes import statements found in .pth files located in site-packages at startup. This caused cook.py to run in every Python process, including IDEs, CI pipelines, and background services. The script collected sensitive data such as SSH keys, cloud credentials, CI/CD secrets, browser passwords, and LLM provider tokens. It then encrypted this data and exfiltrated it to a domain controlled by the attackers, www.litellm[.]dev.

Second, the sitecustomize.py file established a persistent backdoor. This script launched a background daemon that checked a remote GitHub file every hour for a server address. Upon receiving instructions, the daemon would download and execute additional code from that server. The attackers obfuscated the code within cook.py using base64 encoding and zlib compression, wrapping approximately 61 KB of Python code in a single execution line to evade simple static analysis.

Forensic evidence suggests the compromise occurred within the maintainer’s private release pipeline rather than through a public GitHub Actions run. The timestamps on the compiled wheels indicated separate native builds for macOS, Linux, and Windows, consistent with a local or private CI environment. The absence of provenance attestations on PyPI and the mismatch between the git tag and the source distribution further support the theory that an attacker modified the source code before it entered the build system, possibly using compromised credentials or a private branch.

Key details

• Affected version: Only LiteLLM 1.107.0 on PyPI was compromised; previous and release candidate versions are safe.
• Injection method: A modified pyproject.toml file instructed the maturin build tool to include a malicious cook/ directory in the wheel.
• Persistence: The malware used cook.pth and sitecustomize.py to execute automatically upon any Python process startup.
• Data theft: The stealer targeted SSH keys, cloud credentials, AI tokens, and browser passwords, sending them to www.litellm[.]dev.
• Source mismatch: The git tag v1.107.0 pointed to a commit with version 1.108.0, while the sdist matched a later commit with manual edits to revert the version and add the payload.
• Platform impact: All seven wheel variants (Linux, macOS, Windows) contained the malicious files, ensuring cross-platform infection.

Why it matters

This incident demonstrates that verifying source code on public repositories like GitHub is insufficient for ensuring supply chain security. Attackers can intercept the build process or modify artifacts after the source is tagged but before publication. For engineering teams, this means that trusting a package solely based on its repository history is risky. The use of .pth files to achieve code execution without explicit imports bypasses many standard security checks that look for dangerous function calls in application code.

Furthermore, the lack of provenance attestations on PyPI made it difficult to immediately verify the origin of the compiled wheels. Without cryptographic proof linking the built artifact to a specific, verified build process, defenders must rely on reactive forensic analysis. This delay allows malicious packages to remain in circulation longer, increasing the window of exposure for organizations that automate dependency updates.

What you can do

• Immediately uninstall LiteLLM version 1.107.0 if it is present in any environment: pip uninstall litellm==1.107.0.
• Rotate all credentials, API keys, and secrets stored on machines that may have installed the compromised version.
• Check for the presence of cook.pth, cook.py, and sitecustomize.py in your Python site-packages directory.
• Pin dependencies to known good versions, such as 1.106.2 or 1.107.0rc2, until a verified patch is released.
• Enable dependency provenance checks where available and prefer packages that provide attestation metadata.
• Monitor network logs for outbound connections to www.litellm[.]dev or unusual data exfiltration patterns.