Critical Supply Chain Attack: LiteLLM 1.82.8 on PyPI Contains Credential-Stealing Malware

URGENT: If you installed litellm==1.82.8 from PyPI in the past 48 hours, your credentials have likely been compromised. A malicious .pth file embedded in the package automatically executes on every Python interpreter startup, harvesting environment variables, SSH keys, cloud credentials, and cryptocurrency wallets before exfiltrating them to an attacker-controlled server.

What Happened: A Sophisticated Supply Chain Compromise

On March 24, 2026, security researchers discovered that the LiteLLM 1.82.8 wheel package on PyPI contained a malicious file named litellm_init.pth. This 34KB file exploits a standard Python feature—.pth files in site-packages are automatically executed every time the Python interpreter starts, with no import statement required.

The malicious payload was double base64-encoded to evade detection. When decoded, it performs systematic credential harvesting from the host system before encrypting and exfiltrating the data to https://models.litellm.cloud/—note the domain uses .cloud rather than LiteLLM's official .ai domain.

The attack was first reported via GitHub issue #24512, which quickly gained significant attention from the security community. The issue has since received hundreds of comments analyzing the attack vector and discussing broader supply chain security implications.

The Malicious Payload: What It Steals

The credential-stealing script is comprehensive in its data collection. According to the security analysis, it harvests:

System Information: Hostname, username, kernel version, network interfaces, and routing tables. This provides the attackers with context about each compromised machine.

Environment Variables: The entire environment is captured via printenv, which typically includes API keys, database passwords, authentication tokens, and other secrets developers store in their shell environment.

SSH Keys: All common SSH private key formats are targeted—RSA, Ed25519, ECDSA, and DSA keys from ~/.ssh/, along with authorized_keys, known_hosts, and SSH configuration files.

Cloud Credentials: AWS credentials from ~/.aws/ including the IMDS token, Google Cloud credentials from ~/.config/gcloud/, Azure credentials from ~/.azure/, and Kubernetes configurations from ~/.kube/.

Development Tools: Docker configs, npm credentials, Vault tokens, netrc files, MySQL and PostgreSQL password files, shell history files, and Git credentials.

Cryptocurrency Wallets: The payload specifically searches for Bitcoin, Litecoin, Dogecoin, Zcash, Dash, Ripple, Monero, Cardano, Solana, and Ethereum keystores.

SSL/TLS Keys: Private keys from /etc/ssl/private/ and Let's Encrypt certificates.

How the Attack Works

The attack leverages Python's site module behavior. When Python starts, it automatically executes any .pth files found in site-packages directories. This is a legitimate feature used by packages to configure the Python environment, but it can be abused for malicious code execution.

The LiteLLM package's RECORD file—PyPI's manifest of package contents—explicitly lists the malicious file: litellm_init.pth,sha256=ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg,34628. This confirms the file was part of the official wheel distribution, not added post-installation.

The payload uses a two-stage process. First, it collects all sensitive data and writes it to a temporary file. Then it generates a random 32-byte AES-256 session key, encrypts the collected data, and encrypts that session key with a hardcoded 4096-bit RSA public key. The encrypted archive is then exfiltrated via a POST request to the attacker's server.

Root Cause: CI/CD Compromise via Trivy

The LiteLLM team has confirmed that the compromise originated from Trivy, a popular container security scanner used in their CI/CD pipeline. The attack chain illustrates how a single compromised dependency can cascade through the software supply chain:

A compromised Trivy dependency gained access to the CI/CD environment, which contained the PyPI publishing token as an environment variable. The attackers used this token to publish the malicious versions 1.82.7 and 1.82.8 directly to PyPI.

This type of supply chain attack is becoming increasingly common. The Trivy compromise itself appears to be part of a broader campaign affecting multiple projects, with security researchers noting that similar attacks may continue for months as the full scope of the compromise unfolds.

Who Is Affected

Anyone who installed litellm==1.82.8 via pip during the affected window is at risk. This includes:

Local Development Machines: Developers who ran pip install litellm or updated their dependencies in the past 48 hours.

CI/CD Pipelines: Automated builds that install LiteLLM as part of their dependency resolution.

Docker Containers: Images built with the compromised version.

Production Servers: Any deployment that performed a fresh install or update.

The LiteLLM team has clarified that customers using the official LiteLLM Proxy Docker image with pinned dependencies were not affected, as those images use a requirements.txt with fixed versions rather than installing directly from PyPI.

Immediate Actions Required

If you may have installed the compromised version, take these steps immediately:

Check for the Malicious File: Search your Python site-packages directories for litellm_init.pth. You can use this command: find $(python -c "import site; print(' '.join(site.getsitepackages()))") -name "litellm_init.pth" 2>/dev/null

Rotate All Credentials: Assume any credential present on affected systems is compromised. Rotate API keys, database passwords, SSH keys, cloud credentials, and any other secrets stored in environment variables or configuration files.

Review Access Logs: Check your cloud provider access logs, API usage logs, and authentication logs for suspicious activity from March 24-25, 2026.

Audit GitHub/GitLab Activity: Review recent commits, pull requests, and access logs for unauthorized activity.

Uninstall and Reinstall: Remove the compromised package and reinstall from a known-good version. The malicious versions have been yanked from PyPI.

Lessons for the Ecosystem

This incident highlights several critical supply chain security issues. The Hacker News discussion revealed widespread concern about CI/CD security practices, with commenters noting that the PyPI publish token had broader permissions than necessary.

Many developers argued for OIDC-based trusted publishing rather than long-lived tokens, which would have prevented this specific attack vector. Others emphasized the need for better sandboxing of CI/CD tools, suggesting that security scanners like Trivy should not have access to publish credentials.

The incident also sparked debate about Python's .pth file mechanism. While legitimate packages use this feature for valid purposes, its automatic execution capability makes it an attractive target for attackers. Some commenters suggested that package managers should warn users when packages contain .pth files.

FAQ

How do I know if I was affected?

Check if you have litellm_init.pth in any Python site-packages directory. Also check your pip logs or dependency lock files for version 1.82.8. If you installed or updated LiteLLM between March 23-25, 2026, assume compromise and rotate credentials.

What if I use Docker containers?

Docker deployments are somewhat safer because credentials are less likely to be mounted into containers, but any environment variables or mounted volumes containing secrets would still be at risk. Rebuild your images with a clean LiteLLM version and rotate any secrets used in your container environment.

Is LiteLLM safe to use now?

The LiteLLM team has removed the compromised versions from PyPI, rotated all maintainer accounts, deleted all CI/CD tokens, and engaged Google's Mandiant security team for incident response. New releases are paused pending a complete supply chain security review. The team has created new maintainer accounts (@krrish-berri-2 and @ishaan-berri) with fresh credentials.

How can I protect against similar attacks in the future?

Use dependency pinning with lock files, verify package checksums, run security scanners in isolated CI jobs without access to publish tokens, consider using trusted publishing via OIDC instead of long-lived PyPI tokens, and maintain a rapid credential rotation capability. Also consider using virtual environments and container isolation for sensitive development work.

What about other packages that might be compromised?

Security researchers are actively investigating the broader Trivy compromise. Monitor security advisories from any projects that use Trivy in their CI/CD pipelines. The full scope of this supply chain attack may not be known for days or weeks.

Should I stop using LiteLLM?

The team's incident response has been transparent and thorough. They identified the attack vector, removed the malicious packages, rotated all credentials, and engaged professional security assistance. While concerning, this appears to be a victim of a broader supply chain attack rather than negligent security practices. Evaluate your risk tolerance and consider alternatives, but the project appears committed to security going forward.