The LiteLLM Supply Chain Attack: What Every AI Team Needs to Know

On March 24, 2026, two malicious versions of LiteLLM — the most popular open-source LLM proxy with 3.4 million daily downloads — were published to PyPI. For approximately three hours, anyone who ran pip install litellm received a backdoored package that harvested SSH keys, cloud credentials, Kubernetes tokens, and environment variables.

The attack was Phase 9 of an ongoing campaign by the threat actor TeamPCP, which had already compromised Trivy (Aqua Security's vulnerability scanner), Checkmarx KICS, and 80+ npm packages in the preceding five days.

This wasn't a theoretical vulnerability. This was active, weaponized credential theft targeting AI infrastructure at scale.

---

Timeline of the Attack

---

What the Malicious Code Did

The attack was sophisticated and multi-staged. Here's the technical breakdown:

Stage 1: Initial Execution

Version 1.82.7 embedded malicious code inside proxy_server.py — it only executed when the LiteLLM proxy module was imported.

Version 1.82.8 was significantly more dangerous. It included a litellm_init.pth file — a Python mechanism where executable lines in .pth files run automatically during interpreter startup. This means any Python process on the system would trigger the payload, not just LiteLLM imports.

Stage 2: Credential Harvesting

The payload systematically collected:

Stage 3: Encrypted Exfiltration

Harvested data was encrypted with AES-256 session keys wrapped with RSA-4096 and exfiltrated via POST requests to models.litellm[.]cloud — a domain designed to look like legitimate LiteLLM infrastructure. The request header X-Filename: tpcp.tar.gz was the signature of TeamPCP's tooling.

Stage 4: Persistence & Lateral Movement

The malware installed:

• Systemd backdoor at ~/.config/sysmon/sysmon.py with a persistent user unit
• C2 polling to checkmarx[.]zone/raw for follow-on payloads
• Kubernetes propagation — when service tokens were available, it created privileged node-setup-* pods for cluster-wide compromise

Stage 5: Destructive Payload

In a particularly alarming detail: the Kubernetes payload included geolocation-based logic. Systems geolocated to Iran received a kamikaze container that deleted the host filesystem and force-rebooted the node. All other systems received persistent backdoors.

---

Why This Matters for AI Teams

LiteLLM is foundational infrastructure for AI teams. It's the de facto standard for:

• LLM proxy routing — managing multiple AI providers (OpenAI, Anthropic, Google, etc.)
• API key management — centralizing credentials for LLM endpoints
• Cost tracking — monitoring token usage across providers
• Rate limiting — preventing API abuse

This means LiteLLM deployments typically have access to every API key in the organization's AI stack. A compromised LiteLLM instance exposes:

• OpenAI, Anthropic, Google, and other LLM provider API keys
• Internal service credentials
• Database connection strings
• Cloud infrastructure access

The blast radius of this single package compromise is enormous precisely because LiteLLM sits at the center of AI infrastructure.

---

LiteLLM's History of Security Issues

The March 2026 supply chain attack was the most severe incident, but LiteLLM has had a pattern of security vulnerabilities over the past two years:

The pattern reveals a consistent theme: insufficient input validation on parameters that control server-side behavior — exactly the type of vulnerability class that requires deep security testing to catch.

---

How Nebula Detects These Vulnerability Classes

At Breachline, we built Nebula specifically to find the types of vulnerabilities that led to this incident — and the types of vulnerabilities that existed in LiteLLM long before the supply chain attack.

Supply Chain Analysis

Nebula's supply_chain_scan capability analyzes dependency trees for:

• Known vulnerable versions — cross-referencing against CVE databases in real-time
• Typosquatting detection — identifying packages with names similar to legitimate dependencies
• Dependency confusion — checking for internal package names that could be hijacked on public registries
• Version pinning audit — flagging unpinned dependencies that are vulnerable to substitution attacks

SSRF Detection

The LiteLLM SSRF vulnerability (allowing api_base manipulation) is precisely the type of finding Nebula excels at. When Nebula encounters an API endpoint that accepts URL parameters, it systematically tests:

• Internal network access (http://127.0.0.1, http://169.254.169.254)
• Cloud metadata endpoints
• Protocol smuggling (file://, gopher://)
• DNS rebinding scenarios

In our recent benchmark testing, Nebula successfully identified and exploited SSRF vulnerabilities across 3 different challenge scenarios — including SSRF via image fetching and SSRF via markdown rendering.

SQL Injection

LiteLLM's SQL injection vulnerabilities (CVE-2025-45809, CVE-2024-5225) allowed attackers to execute arbitrary commands through API management endpoints. Nebula tests every input parameter for injection, including:

• API keys and authentication tokens as injection vectors
• Management endpoints that developers often assume are "internal only"
• Blind SQL injection via time-based and boolean-based techniques

Authentication & Authorization Flaws

The credential leakage issues in LiteLLM (CVE-2024-9606, CVE-2025-0330) represent broken access controls — sensitive data exposed through insufficient masking or improper error handling. Nebula tests for:

• API key exposure in error responses and logs
• Authentication bypass via header manipulation
• Privilege escalation through parameter tampering
• Improper access controls on administrative endpoints

---

Protecting Your LLM Infrastructure

Immediate Actions (If You Use LiteLLM)

If your organization installed LiteLLM between March 24 10:39 UTC and 16:00 UTC:

1. Treat the system as fully compromised — removing the package alone is not sufficient
2. Rotate all credentials — API keys, cloud credentials, SSH keys, database passwords, Kubernetes tokens
3. Check for persistence — look for litellm_init.pth in site-packages, ~/.config/sysmon/sysmon.py, and node-setup-* pods in Kubernetes
4. Audit CI/CD pipelines — any artifacts built during the exposure window may be compromised
5. Monitor for C2 traffic — watch for connections to models.litellm[.]cloud and checkmarx[.]zone

Long-Term Recommendations

---

The Bigger Picture

The LiteLLM incident illustrates a fundamental challenge in AI infrastructure security: the tools we use to build AI systems are themselves attack surfaces.

LiteLLM had 6 known CVEs in 2025 alone — SSRF, SQL injection, RCE, credential leakage. Each of these was a window of opportunity for attackers. The March 2026 supply chain attack simply demonstrated what happens when those windows aren't closed fast enough.

The organizations that weathered this incident best were those running:

• Pinned dependencies with hash verification
• Isolated deployment environments limiting credential exposure
• Continuous security testing that would have caught the SSRF and SQLi vulnerabilities before they became entrypoints

The question isn't whether your AI infrastructure will be targeted. It's whether you'll find the vulnerabilities before the attackers do.

---

Breachline Nebula provides continuous, autonomous security testing for web applications and AI infrastructure. Learn more at breachline.io.

Sources: LiteLLM Official Security Update, Datadog Security Labs Analysis, Snyk Research, Arctic Wolf Advisory