If you build AI applications in Python, there is a very good chance LiteLLM is somewhere in your stack — or in the stack of a tool you depend on. It is the de facto universal adapter for LLM APIs: one library that speaks to OpenAI, Anthropic, AWS Bedrock, Google VertexAI, and over a hundred other providers. It touches your .env files, your API keys, your Kubernetes secrets. That is exactly why it was targeted.

On March 24, 2026, two versions of LiteLLM were quietly pushed to PyPI. They looked legitimate. They passed no official CI/CD process. They contained a multi-stage credential stealer that executed silently in the background of every Python process on infected machines. By the time the community raised the alarm, the window had been open for over five hours.

This is not just an incident report. It is a blueprint for how the next wave of AI supply chain attacks will work — and why your current defenses are probably not sufficient.

From a Vulnerability Scanner to 95 Million Downloads

This attack did not begin with LiteLLM. It began weeks earlier, as part of a coordinated campaign by a threat group known as TeamPCP, which emerged in late 2025 and has since systematically targeted the developer tooling ecosystem.

What the Malware Actually Did

The payload was layered, encrypted, and persistent. Understanding it mechanically is the first step toward building defenses that actually work.

Stage 01 — Silent Execution via .pth Files

Python’s .pth file mechanism is a legitimate feature for extending the module search path. When the malicious LiteLLM was installed, it dropped a file called litellm_init.pth into the site-packages directory. Python executes .pth files automatically on startup — no import needed, no user action required. Every Python process on the machine became an execution vector.

# What a normal .pth file looks like (benign)
/home/user/myproject/src

# What litellm_init.pth contained
import base64; exec(base64.b64decode('..obfuscated multi-stage payload..'))

Stage 02 — Credential Harvesting

The decoded payload systematically swept the host for every secret a modern AI developer keeps on their machine. Its target list was comprehensive by design — LiteLLM was chosen precisely because it sits adjacent to all of these:

Stage 03 — Encrypted Exfiltration

Collected data was not sent in plaintext. The malware used a hardcoded 4096-bit RSA public key to encrypt a random AES-256-CBC session key, then encrypted the harvested data with that session key, bundled everything into a tar archive, and POSTed it to https://models.litellm.cloud — a convincingly named domain that is not part of legitimate LiteLLM infrastructure.

# 1. Check your installed version
pip show litellm | grep Version

# 2. Look for the malicious .pth file in site-packages
find $(python -c "import site; print(site.getsitepackages()[0])") \
  -name "litellm_init.pth" 2>/dev/null

# 3. Check for persistence mechanisms
ls ~/.config/sysmon/sysmon.py 2>/dev/null
ls ~/.config/systemd/user/sysmon.service 2>/dev/null

# 4. Purge package cache to prevent re-infection from cached wheels
pip cache purge
# Or if using uv:
rm -rf ~/.cache/uv

Stage 04 — Lateral Movement & Kubernetes Persistence

This is where the attack shifts from credential theft to full infrastructure control. If a Kubernetes service account token was present, the malware read all cluster secrets across all namespaces and attempted to create a privileged alpine:latest pod on every node in kube-system. Each pod mounted the host filesystem and installed a persistent backdoor at /root/.config/sysmon/sysmon.py via a systemd user service.

Why AI Tooling Is the New High-Value Attack Surface

This attack is not a one-off. It is proof of concept for a systematic strategy targeting the AI software supply chain. Security-adjacent tooling has broad, trusted access by design — compromising one tool hands the attacker everything that tool was trusted to touch.

If You Were Affected: Stop, Rotate, Audit

Immediate Response Checklist

• Remove LiteLLM v1.82.7 and v1.82.8 from all environments and purge pip/uv caches
• Delete ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service if present
• If running Kubernetes: audit kube-system for pods named node-setup-* and review all cluster secrets
• Rotate all credentials on any affected machine — SSH keys, cloud provider keys, API keys, database passwords
• Review outbound network logs for connections to models.litellm.cloud
• Treat affected CI/CD runners as fully compromised — rotate secrets and rebuild clean base images
• Engage forensic analysis if production infrastructure or customer data systems were exposed

Hardening Your AI Dependency Chain

Incident response addresses the immediate crisis. The structural problem is that most AI development workflows are built for speed, not security. Here is how to change that without killing velocity.

01 — Pin Your Dependencies. Always.

The single most impactful mitigation for supply chain attacks is version pinning. An unpinned pip install litellm will silently pull whatever the latest version is. A pinned install will not.

# Vulnerable: always pulls latest, no verification
pip install litellm

# Safe: locked to a specific verified version
pip install litellm==1.82.6

# Even better: lock file with hash verification
pip install --require-hashes -r requirements.txt

02 — Deploy a Dependency Firewall for PyPI

Tools like Sonatype Repository Firewall, Socket.dev, or a private package mirror with allowlisting can intercept malicious packages before they reach your environment. This is the automated equivalent of a security review at the point of ingestion — and it would have blocked this attack in real time.

03 — Apply Zero-Trust Principles to Your Build Pipeline

• Pin all GitHub Actions to specific commit SHAs, not mutable tags like @v3
• Use ephemeral, short-lived credentials in CI (OIDC tokens where possible — never static API keys)
• Perform atomic credential rotation: revoke old credentials before activating new ones — a rotation window is an attack window
• Separate build environments from environments with production secret access
• Audit and minimize the secrets accessible in each individual pipeline job

04 — Scan New Dependencies Before Merging

Integrate automated supply chain scanning into your PR process. Tools like pip-audit, Snyk, or Grype can flag known-malicious packages before they land in your main branch.

# Install and run pip-audit against your current environment
pip install pip-audit
pip-audit

# Audit a specific requirements file with hash verification
pip-audit --require-hashes -r requirements.txt

05 — Treat AI Credentials Like Production Secrets From Day One

Okta Threat Intelligence warned in 2025 that rapid AI agent adoption was creating “identity debt” — developers connecting AI agents directly to production resources with static, long-lived tokens stored in plaintext config files. This attack is that prediction materializing. The fix is governance: short-lived tokens, scoped access, and a formal review process before any AI component touches production data.

Attack Surface Mapping: Why AI Tooling Is Targeted

TeamPCP has exclusively targeted security-adjacent and AI-adjacent tooling. The pattern is intentional — these tools run with broad access because that is how they function. The following table maps each tool type to its blast radius when compromised:

The AI Supply Chain Is Now a Primary Attack Surface

The LiteLLM attack is not an isolated incident. It is the clearest signal yet that threat actors have identified the AI software supply chain as a high-leverage, underdefended target. LLM gateway libraries, agent frameworks, and AI developer tools all share a common characteristic: they are adopted fast, often without security review, and they sit in privileged positions between applications and sensitive infrastructure.

The organizations most at risk are not necessarily the least sophisticated. They are the most experimental — teams moving quickly to build with AI that have not yet established the governance practices that security-mature organizations apply to production dependencies. The blast radius of this attack is largely a story about AI adoption outpacing AI security.

This article was written on March 28, 2026, four days after the incident. The TeamPCP campaign is ongoing. For the latest indicators of compromise, follow ReversingLabs and Help Net Security. If you believe your systems are affected, contact LiteLLM via their official security disclosure channel and engage your incident response team immediately.

Sources: LiteLLM official security update (docs.litellm.ai), FutureSearch technical analysis (futuresearch.ai), Sonatype Security Research, ReversingLabs TeamPCP campaign tracking, Help Net Security, Okta Threat Intelligence, AppOmni CISO statement.