LiteLLM PyPI Supply Chain Attack: What Happened and How to Protect Your Organization

TL;DR

If your organization installed LiteLLM 1.82.7 or 1.82.8 from PyPI, rotate all credentials on affected machines immediately. The malware harvested SSH keys, cloud credentials, environment variables, and Kubernetes configs. Even if you don't use LiteLLM directly, it may have been pulled as a transitive dependency by tools like MCP plugins.

What Is LiteLLM?

LiteLLM is a widely used Python library that provides a unified interface for calling over 100 LLM providers, including OpenAI, Anthropic, Azure, and AWS Bedrock. It is popular among AI engineering teams for its ability to abstract away provider-specific API differences and simplify LLM integration in production applications.

Its widespread adoption makes it a high-value target for supply chain attacks. A single compromised version can cascade across thousands of organizations, particularly those building AI-powered products and internal tools.

The Attack: What Happened

On March 24, 2026, at 10:52 UTC, a compromised version of LiteLLM (v1.82.8) was published to PyPI. Shortly after, version 1.82.7 was also found to contain the same malicious payload. By 13:03 UTC, a GitHub issue reporting the compromise was closed as "not planned," suggesting the maintainer's account had been fully compromised.

The compromised versions were yanked from PyPI by 20:15 UTC on the same day. The attack was discovered by FutureSearch when their engineers noticed anomalous behavior after the package was pulled as a transitive dependency by an MCP plugin in Cursor, an AI-powered code editor.

The Attack Vector: Malicious .pth Files

The attack used a particularly dangerous technique: a malicious Python .pth file named litellm_init.pth.

Python .pth files are typically used to extend the module search path, but they have a lesser-known property: any line starting with import in a .pth file executes automatically on every Python process startup. This means the malicious code ran without any explicit import or function call from the developer. Simply having the package installed was enough.

This is more dangerous than the postinstall script attacks commonly seen in npm supply chain incidents. With .pth files, the payload executes every time Python starts, not just once during installation.

Stage 1: Credential Harvesting

Once activated, the malware systematically collected sensitive data from the infected machine:

• SSH keys (~/.ssh/)
• Environment files (.env, .env.local, .env.production)
• Cloud provider credentials (AWS credentials, GCP service accounts, Azure tokens)
• Kubernetes configs (~/.kube/config)
• Database passwords and connection strings
• Git configuration (.gitconfig)
• Shell history (.bash_history, .zsh_history)
• Cryptocurrency wallet files
• Cloud metadata endpoints (queried for instance credentials)

Stage 2: Encrypted Exfiltration

The collected data was encrypted using 4096-bit RSA and AES-256-CBC encryption, then sent via HTTP POST to https://models.litellm.cloud/, a domain designed to look like legitimate LiteLLM infrastructure but controlled by the attackers.

The use of strong encryption made network-level inspection of the exfiltrated data nearly impossible, even for organizations with SSL/TLS inspection in place.

Stage 3: Kubernetes Persistence

If Kubernetes tokens were found on the compromised machine, the malware went a step further. It attempted to:

• Create privileged pods across cluster nodes
• Install persistent backdoors at /root/.config/sysmon/sysmon.py
• Establish long-term access to production infrastructure

This escalation from developer workstation to production cluster is exactly the kind of lateral movement that makes supply chain attacks devastating.

The Accidental Fork Bomb

Ironically, the malware contained a critical bug. It spawned child processes via subprocess.Popen, but since .pth files trigger on every Python interpreter startup, each child process spawned more children, creating an exponential fork bomb that crashed affected machines. This unintentional denial-of-service actually helped alert victims to the compromise, as machines became unresponsive shortly after installation.

Why This Matters for Your Organization

Transitive Dependencies Are Invisible Attack Surface

LiteLLM is not always installed directly. It can appear as a transitive dependency pulled in by other tools. In this case, FutureSearch's engineers were exposed because an MCP plugin in Cursor depended on LiteLLM. Many organizations may not even realize they have LiteLLM in their dependency tree.

Run pip show litellm or check your requirements.txt, poetry.lock, or pip freeze output to verify whether you were affected.

AI Tooling Expands the Blast Radius

As organizations adopt AI-powered development tools (code editors, MCP plugins, AI agents), the dependency trees grow deeper and less predictable. A library like LiteLLM, which serves as connective tissue between AI tools and LLM providers, becomes a single point of failure for a large portion of the AI development ecosystem.

Developer Machines Are High-Value Targets

Developer workstations typically hold the keys to the kingdom: SSH access to production servers, cloud provider credentials, database connection strings, and CI/CD tokens. A single compromised developer machine can provide an attacker with everything needed to breach production infrastructure.

What Compliance Frameworks Say About Supply Chain Security

Supply chain attacks like this are precisely why compliance frameworks mandate controls around vendor risk management and secure development practices.

SOC 2

SOC 2 addresses supply chain security through several Trust Services Criteria:

• CC6.1 (Logical and Physical Access Controls): Organizations must implement controls over the systems and software they deploy, including third-party libraries
• CC7.1 (System Operations): Requires monitoring for anomalous behavior, including in build and deployment pipelines
• CC8.1 (Change Management): Mandates that changes to system components, including dependency updates, are authorized, tested, and approved
• CC3.2 (Risk Assessment): Organizations must identify and assess risks from third-party dependencies

ISO 27001

ISO 27001 (2022 revision) includes specific controls relevant to this type of attack:

• A.8.19 (Installation of Software on Operational Systems): Requires procedures for controlling software installation
• A.8.25 (Secure Development Life Cycle): Mandates security throughout the development process, including dependency management
• A.5.21 (Managing Information Security in the ICT Supply Chain): Explicitly addresses risks from the technology supply chain
• A.8.8 (Management of Technical Vulnerabilities): Requires timely identification and remediation of vulnerabilities in third-party components

Both frameworks recognize that your security posture is only as strong as your weakest dependency. Implementing the controls below is not just good security practice, it is a compliance requirement.

How to Protect Your Organization

Immediate Actions (If You Were Affected)

1. Check if you installed LiteLLM 1.82.7 or 1.82.8:

   Bash Copy

   1pip show litellm
   2pip freeze | grep litellm

2. Rotate all credentials on any machine that had the compromised version:

   • SSH keys
   • Cloud provider credentials (AWS, GCP, Azure)
   • API tokens and secrets in .env files
   • Kubernetes configs and service account tokens
   • Database passwords
   • Git tokens (GitHub, GitLab)

3. Audit access logs for unusual activity since March 24, 2026

4. Check Kubernetes clusters for unauthorized pods or backdoors at /root/.config/sysmon/sysmon.py

Preventive Measures for All Teams

Pin Dependencies and Use Lockfiles

Never allow floating version ranges in production. Use exact version pinning and commit lockfiles:

1# Use pip-compile to generate pinned requirements
2pip-compile --generate-hashes requirements.in
3
4# Or use Poetry with locked dependencies
5poetry lock
6poetry install --no-update

The --generate-hashes flag adds SHA-256 hashes for each package, ensuring that even if a version is re-published with different contents, the installation will fail.

Verify Package Integrity

Use tools that check package signatures and checksums:

1# Verify installed packages against known hashes
2pip install --require-hashes -r requirements.txt

Scan for Vulnerabilities in CI/CD

Integrate dependency scanning into your CI/CD pipeline:

1# Use pip-audit for Python
2pip install pip-audit
3pip-audit
4
5# Or use Safety
6pip install safety
7safety check

Restrict .pth File Execution

Python 3.13+ supports the -P flag to disable .pth processing:

1python -P your_script.py

For environments where you cannot control the Python invocation, audit installed .pth files:

1find $(python -c "import site; print(site.getsitepackages()[0])") -name "*.pth" -exec grep -l "^import" {} \;

Use Virtual Environments and Containers

Isolate development environments to limit the blast radius of a compromised package:

1# Always use virtual environments
2python -m venv .venv
3source .venv/bin/activate
4
5# For production, use minimal container images
6FROM python:3.13-slim

Never Store Credentials in Local Files

Use secrets managers instead of .env files or shell configs:

1# With 1Password CLI
2export AWS_ACCESS_KEY=$(op read op://vault/aws/access-key)
3
4# With AWS Secrets Manager
5export DB_PASSWORD=$(aws secretsmanager get-secret-value --secret-id prod/db --query SecretString --output text)

Monitor for Anomalous Network Activity

Configure network monitoring to detect unexpected outbound connections from developer machines and CI/CD runners. The exfiltration endpoint models.litellm.cloud used a domain that mimicked legitimate infrastructure, making it harder to catch without proper DNS monitoring.

Security Checklist

Within 24 Hours

• Verify LiteLLM version across all environments
• Rotate credentials on affected machines
• Audit Kubernetes clusters for unauthorized workloads
• Review access logs for suspicious activity

Within 72 Hours

• Pin all Python dependencies with hashes
• Add dependency scanning to CI/CD pipelines
• Audit transitive dependency trees for unexpected packages
• Implement network monitoring on developer machines

Ongoing

• Use lockfiles and hash verification for all package managers
• Adopt secrets management (Vault, 1Password CLI, AWS Secrets Manager)
• Isolate development environments with virtual environments and containers
• Review and restrict .pth file execution in Python environments
• Include supply chain security in your incident response procedures

Conclusion

The LiteLLM supply chain attack follows a pattern we have seen accelerating throughout 2025 and 2026, from the Nx npm compromise to the eslint-config-prettier incident. Attackers are increasingly targeting the tools developers trust most, knowing that a single compromised package can grant access to thousands of organizations.

The .pth file technique used in this attack is particularly concerning because it bypasses the usual installation hooks that security tools monitor. It highlights the need for defense-in-depth: pinned dependencies, hash verification, credential isolation, network monitoring, and developer environment hardening all working together.

For organizations pursuing SOC 2 or ISO 27001 certification, supply chain security is not optional. These frameworks explicitly require controls around third-party software, change management, and vulnerability management. The practices outlined above are not just recommendations, they are compliance obligations.

If you need help implementing supply chain security controls as part of your compliance program, get in touch with Bastion. We help startups and SMBs build security programs that address real threats, not just check boxes.