The LiteLLM Backdoor: How Trusted AI Tooling Became a Credential Thief

What Happened

On the morning of March 24, 2026, a threat actor group calling themselves TeamPCP published two backdoored versions of litellm — a Python library that provides a unified interface for routing requests to over 100 large language model APIs, including OpenAI, Anthropic, AWS Bedrock, and Google Vertex AI.

LiteLLM is downloaded roughly 3.4 million times per day and sits at approximately 95 million monthly downloads on PyPI, making it one of the most-used libraries in the AI developer ecosystem. Its central role in AI agent frameworks, MCP servers, and production LLM pipelines made it a high-value, high-yield target: any system running it is likely storing API keys and cloud credentials.

The attack was not a vulnerability in the software itself. It was a supply chain compromise — the attackers stole the maintainer’s PyPI publishing token and used it to upload malicious versions that passed all standard integrity checks.

How Credentials Were Stolen: The Trivy Connection

The root of the compromise traces back to a prior attack on Trivy, an open-source security scanner made by Aqua Security. LiteLLM’s CI/CD pipeline used Trivy as part of its build process, pulling it from apt without a pinned version.

TeamPCP had previously compromised Trivy in a separate supply chain campaign. When LiteLLM’s GitHub Actions pipeline ran, it pulled the already-compromised Trivy, which then exfiltrated the PYPI_PUBLISH token from the runner’s environment. With that credential in hand, the attackers had everything they needed to publish packages to PyPI under the legitimate LiteLLM account.

This is the cascading nature of supply chain attacks: a compromised security scanner became the key to backdooring a library trusted by millions.

Attack Timeline

Two Versions, Two Injection Techniques

Unlike many supply chain attacks that use a single method, TeamPCP deployed two different malicious versions with distinct delivery mechanisms, escalating in severity.

Critically, hash verification would not have helped. The malicious content was published using legitimate credentials, so the wheel’s RECORD file contained correct, matching hashes. A pip install --require-hashes check would have passed without warning.

What the Payload Stole

Once triggered, the malware executed a three-stage attack: credential harvesting, lateral movement into Kubernetes clusters, and persistence installation.

Stage 1 — Credential Harvesting

Harvested data was encrypted using a hardcoded 4096-bit RSA public key with AES-256-CBC, bundled into a tar archive, and exfiltrated via HTTP POST to models.litellm.cloud — a domain impersonating the legitimate LiteLLM infrastructure, but not operated by the real LiteLLM team.

Stage 2 — Kubernetes Lateral Movement

If a Kubernetes service account token was present on the machine, the malware read all cluster secrets across all namespaces and attempted to deploy a privileged alpine:latest pod to every node in the kube-system namespace. Each pod mounted the host filesystem and installed additional backdoors.

Stage 3 — Persistence

A backdoor script was written to ~/.config/sysmon/sysmon.py and registered as a systemd user service (sysmon.service), which continuously polled for additional payloads. On Kubernetes nodes, the same mechanism was installed at /root/.config/sysmon/.

Scale of Impact

The malicious versions were live for approximately three hours. Given LiteLLM’s 3.4 million daily download rate, the potential exposure window was significant. According to sources cited by BleepingComputer, the number of credential exfiltration events reached approximately 500,000, though many were duplicates.

The attack’s blast radius was amplified by LiteLLM’s role as a transitive dependency. Many affected users had never directly installed LiteLLM; it arrived silently as a dependency of AI agent frameworks, MCP server plugins, and LLM orchestration tools. The researcher who first reported the issue had pulled it in via a Cursor MCP plugin — she never ran pip install litellm herself.

The victim never ran pip install litellm. It was pulled in automatically by their AI development tooling.

— ARMO Security Research Blog, March 2026

Am I Affected?

You may be affected if any of the following are true:

• You installed or upgraded litellm via pip on March 24, 2026 between 10:39 and 13:38 UTC
• You ran pip install litellm without a pinned version and may have received v1.82.7 or v1.82.8
• You built a Docker image during this window with an unpinned pip install litellm
• A project you use (e.g. an AI agent framework or MCP server) pulled in LiteLLM as an unpinned transitive dependency

You are not affected if you were running the official LiteLLM Proxy Docker image, which pins its dependencies in requirements.txt and was not using the compromised PyPI packages.

# Check if you have a compromised version installed
pip show litellm

# If output shows version 1.82.7 or 1.82.8:
pip uninstall litellm
pip cache purge

# Also check uv caches
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

Remediation Checklist

If you suspect compromise, treat the machine as fully breached. Work through each step:

• Uninstall litellm 1.82.7 or 1.82.8 and purge all package caches immediately
• Check for the persistence backdoor: ~/.config/sysmon/sysmon.py and ~/.config/systemd/user/sysmon.service
• Rotate all credentials: SSH keys, AWS/GCP/Azure tokens, Kubernetes configs, API keys in .env files, database passwords
• Inspect Kubernetes clusters for unauthorized pods in kube-system and audit all cluster secrets for access by unknown principals
• Review outbound network traffic for connections to models.litellm.cloud and related attacker domains
• Check for suspicious temp files: /tmp/pglog, /tmp/.pg_state
• Audit CI/CD pipeline logs for any jobs that installed litellm between 10:39–13:38 UTC on March 24
• For high-risk environments: consider rebuilding containers and reprovisioning infrastructure entirely

Indicators of Compromise (IOCs)

What Actually Works: Defense Recommendations

Pin dependencies with hash locking

Exact version pinning alone (litellm==1.82.6) is necessary but not sufficient — your lockfile could update automatically. What genuinely helps is hash-pinned lockfiles generated by pip-tools --generate-hashes, uv lock, or poetry lock. These ensure you install exactly the artifact you reviewed.

Use a private PyPI mirror with approval gates

Build an internal package mirror that caches only approved versions. New releases must pass security team review before being added. This is one of the few defenses that would have blocked this specific attack.

Restrict Kubernetes service account tokens

LiteLLM’s Kubernetes lateral movement was entirely dependent on finding a mounted service account token. Set automountServiceAccountToken: false on pods that don’t need it. Apply least-privilege RBAC — tokens that do exist should not have cluster-wide list secrets permissions.

Monitor runtime behavior, not just static scans

This attack passed all standard hash verification checks because the malicious content was published with legitimate credentials. Detection requires runtime behavioral signals: egress network monitoring, process behavior analytics (watching for unexpected subprocess.Popen forks at Python startup), and file integrity monitoring on sensitive credential paths.

Audit your transitive dependency tree

Most affected users didn’t directly depend on LiteLLM. Tools like pipdeptree or uv tree reveal the full dependency graph. Know what is in your tree before it becomes a liability.

Broader Context: A Targeted Campaign

The LiteLLM incident is the third confirmed attack in a coordinated campaign attributed to TeamPCP. The group first compromised Trivy, then used that foothold to breach Checkmarx KICS, and finally LiteLLM. The campaign strategy is notable: attack the security and observability tools that developers trust — scanners, CI/CD dependencies — to gain access to the credentials of their users downstream.

BleepingComputer reports that TeamPCP has also been found deploying a “CanisterWorm” backdoor targeting Kubernetes clusters, with a separate kill switch that wipes machines detected as being configured for Iran.

The target selection pattern — a container scanner, an infrastructure scanning tool, and an AI model routing library — focuses on tools with elevated access to automated pipelines and production secrets. LiteLLM, sitting between applications and over 100 AI service providers, routinely handles some of the most sensitive credentials in a modern AI stack.

AI tooling is incredible. It’s also becoming the fattest, most credential-rich target in your entire infrastructure.

— ARMO Security Blog, March 2026

Confirmed Clean Versions

LiteLLM’s security team has audited all releases between v1.78.0 and v1.82.6, verifying SHA-256 digests against corresponding Git commits and scanning for known IOCs. All versions up to and including v1.82.6 are confirmed clean. The current recommended version is v1.82.6. Avoid 1.82.7 and 1.82.8.

For real-time status updates, refer to the official LiteLLM security advisory, the Snyk vulnerability record SNYK-PYTHON-LITELLM-15762713, and GitHub Issue #24512.