The LiteLLM PyPI Attack
A Supply Chain Postmortem

A Maintainer Account Gets Hijacked

On March 24, 2026 at 10:39 UTC, litellm==1.82.7 was uploaded to PyPI. Thirteen minutes later, 1.82.8 followed. Neither version had a corresponding Git tag or GitHub release. Both were uploaded directly by the threat actor after compromising the PyPI account of krrishdholakia, the litellm maintainer — bypassing the project's entire CI/CD pipeline.

The attack was only discovered by accident. A developer at FutureSearch installed an MCP plugin in Cursor IDE. That plugin pulled in litellm as a transitive dependency. Within seconds, the machine ran out of RAM and crashed — caused by an exponential fork bomb, a bug in the malware itself. Without that bug, the attack would have been completely silent.

Anatomy of the Payload

The attack operates differently across the two versions, with 1.82.8 representing an escalated, more aggressive iteration. Here's what version 1.82.8 does from the moment litellm is installed:

The .pth Trick — Why No Import Is Needed

Python's site module processes all .pth files in site-packages/ at interpreter startup. The malicious file litellm_init.pth (34,628 bytes, listed in the package's own RECORD) contains:

import os, subprocess, sys; subprocess.Popen([
  sys.executable, "-c",
  "import base64; exec(base64.b64decode('...[34KB of double-encoded payload]...'))"
])

This spawns a child Python process carrying the full payload. Because .pth files trigger on every interpreter startup, the child re-triggers the same file — creating an exponential fork bomb. The fork bomb was not intentional. It is a bug. Without it, this attack would still be undetected in countless environments.

Version 1.82.7 was slightly less aggressive — the payload was embedded directly in proxy/proxy_server.py, requiring an explicit import litellm to trigger. Version 1.82.8 removed that requirement entirely.

What's Safe, What's Not

How to Check if You're Affected

Run these commands on any machine where you use Python-based AI tooling — especially Cursor, Claude Code, or any environment with MCP plugins installed.

pip show litellm
# Look for: Version: 1.82.7 or 1.82.8 → you are affected

find / -name "litellm_init.pth" 2>/dev/null
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null
find ~/.local -name "litellm_init.pth" 2>/dev/null

ls ~/.config/sysmon/sysmon.py 2>/dev/null
ls ~/.config/systemd/user/sysmon.service 2>/dev/null

kubectl get pods -n kube-system | grep node-setup
kubectl get secrets --all-namespaces | grep -i suspicious

# Remove the package
pip uninstall litellm -y

# Purge package manager caches to prevent re-install from cache
rm -rf ~/.cache/uv
pip cache purge

# Remove persistence if found
rm -rf ~/.config/sysmon/
systemctl --user disable sysmon.service 2>/dev/null
rm ~/.config/systemd/user/sysmon.service 2>/dev/null

The MCP Ecosystem Is an Emerging Attack Surface

This attack didn't just exploit a Python package. It exploited a structural property of how modern AI tooling gets assembled — and it landed on machines running Cursor and Claude Code because of it.

MCP (Model Context Protocol) plugins are a young, largely unvetted ecosystem. There is no curated review process. Plugins can pull in arbitrary Python packages. And the machines running these tools — developer workstations, CI runners — are loaded with the exact credentials attackers want.

Claude Code users face compounded risk. Claude Code is an agentic tool with broad file system access and code execution capabilities by design. It also has documented support for LiteLLM proxy as an MCP integration. Beyond the litellm vector, Check Point Research separately disclosed vulnerabilities in Claude Code where malicious repository configuration files could trigger arbitrary shell commands and API key exfiltration simply by opening a project — all issues now patched by Anthropic.

The pattern here is the same across all these attacks: configuration and tooling layers have become part of the execution surface. A .pth file is not code you write. An MCP plugin dependency is not a package you explicitly chose. But both run with full privileges on your machine.

How to Reduce Your Exposure

No single control fully prevents supply chain attacks, but layered defenses significantly shrink the blast radius.

Immediate Action Checklist

• Run pip show litellm in every Python environment on developer machines and CI runners
• Search for litellm_init.pth in all site-packages directories and package manager caches
• Check for persistence indicators: ~/.config/sysmon/ and sysmon.service
• If found: rotate all credentials accessible from that machine immediately
• Pin all projects to litellm<=1.82.6 until a verified clean release is available
• Audit MCP plugins for their transitive dependency trees before installation
• Enable PyPI Trusted Publishers for any packages your team maintains

This Campaign Isn't Over

TeamPCP has now crossed five supply chain ecosystems in under a month — GitHub Actions, Docker Hub, npm, OpenVSX, and PyPI. Each compromised environment yields credentials that unlock the next target. The 13-minute gap between litellm 1.82.7 and 1.82.8 shows an attacker actively iterating during the attack window, escalating the trigger mechanism in real time.

The AI developer tooling ecosystem is a particularly attractive target: high-privilege machines, dense credential environments, a young and fast-moving plugin ecosystem with minimal security review, and the implicit trust developers place in tools they use every day. That combination will continue to be exploited.

The best defense is treating every layer of your tooling stack — not just your own code — as part of your attack surface.