reinkarnation.space / blog

CRITICAL SECURITY ALERT: The LiteLLM PyPI Supply Chain Attack

Published March 25, 2026 | Bhanu Pratap

Back to all posts

If you build AI applications, read this immediately.

On March 24, 2026, two versions of LiteLLM (1.82.7 & 1.82.8) were pushed to PyPI containing devastating, credential-stealing malware. LiteLLM sees roughly 97 million monthly downloads and serves as a foundational dependency across the entire AI engineering ecosystem. This is not just a package issue—it is a full credential compromise event affecting anyone who installed or updated these versions, directly or transitively.

What Happened: A Cascading Supply Chain Attack

The threat actor group known as TeamPCP—the exact same group behind the Trivy and Checkmarx/KICS GitHub Actions compromises earlier in March—executed a masterful, cascading supply chain attack:

  1. LiteLLM's CI/CD pipeline utilized Trivy, which TeamPCP had already subtly compromised a few days prior (March 19).
  2. The compromised Trivy action ran inside LiteLLM's GitHub Actions runner and silently exfiltrated its PYPI_PUBLISH token.
  3. Armed with the token, the attackers pushed malicious versions directly to PyPI, completely bypassing GitHub's standard release flow, code reviews, and branch protections.

The poisoned versions were live for roughly 3 hours before PyPI quarantined them. Given the velocity of the AI space, that window was more than sufficient to cause widespread damage.

How the Malware Operated

The execution was remarkably sophisticated, scaling in severity between the two releases.

Version 1.82.7 embedded a base64-encoded payload directly inside litellm/proxy/proxy_server.py, activating upon import of the library.

Version 1.82.8 escalated to dropping a litellm_init.pth file into Python's site-packages directory. Python's site module automatically executes .pth files on every interpreter startup—meaning no import was required at all. Any script execution, simple pip invocation, or even an IDE language server starting up in the background triggered the payload.

Once triggered, the attack operated in three distinct stages:

Are You Affected? The Transitive Threat

You may be compromised even if you never directly ran pip install litellm. The AI tooling dependency tree is famously deep. The following tools carry LiteLLM as a direct or transitive dependency:

If you installed any of the above without version pinning on March 24, assume full compromise.

Immediate Remediation Steps

Step 1: Confirm Compromise

Run pip show litellm. If the version shows 1.82.7 or 1.82.8, your environment is compromised. Do not simply upgrade—the payload has already executed.

Step 2: Purge the Package

pip uninstall litellm -y
pip cache purge

If you are using uv:

find ~/.cache/uv -name "litellm_init.pth" -delete

Step 3: Check for Persistence Indicators

Check the host filesystem and Kubernetes clusters:

ls ~/.config/sysmon/sysmon.py
ls ~/.config/systemd/user/sysmon.service
kubectl get pods -n kube-system | grep node-setup

Step 4: Rotate ALL Credentials (Crucial)

Treat the machine as fully compromised. You must immediately rotate SSH keys, cloud provider tokens (AWS, GCP, Azure), Kubernetes configs, all .env API keys (OpenAI, Anthropic, etc.), database passwords, CI/CD secrets, and crypto wallet keys.

Step 5: Audit CI/CD and Docker

Any pipeline that installed litellm on March 24 without a pinned version is compromised. All secrets accessible during those runs must be rotated. Any Docker image built during this window must be rebuilt from a clean base.

Step 6: Pin Safely

pip install litellm==1.82.6

Broader Implications for AI Engineering

This attack highlights a deliberate, escalating pattern by TeamPCP targeting the infrastructure of the AI boom. By compromising a security scanner (Trivy), they obtained the credentials to compromise a core infrastructure block (LiteLLM).

As Andrej Karpathy famously noted, we treat dependencies as harmless bricks. But every dependency is arbitrary code running with your full user permissions. The AI tooling ecosystem is particularly exposed because our dependency trees are massive, installations are frequent, and the credentials stored in our environments (LLM API keys, vector DB passwords) are highly valuable.

We are incredibly lucky this incident was discovered—it only came to light because a bug in the payload caused a fork bomb that OOM-crashed an engineer's machine via a Cursor plugin. Without that bug, this could have gone undetected across thousands of production environments for weeks.

CVE/Vuln ID: SNYK-PYTHON-LITELLM-15762713

Safe version: litellm==1.82.6