LiteLLM supply chain attack visualization showing Python package compromise and credential theft

Your AI infrastructure was just compromised. Not through a sophisticated zero-day exploit. Not through a nation-state APT operation. Through a simple pip install command that your developers run dozens of times per day.

On March 24, 2026, versions 1.82.7 and 1.82.8 of LiteLLM - the Python library that serves as the universal gateway for over 100 large language model APIs - were backdoored by TeamPCP, a cybercriminal group that has been systematically dismantling the cloud-native and AI ecosystems. With over 480 million downloads on PyPI and integrations across virtually every major AI agent framework, LiteLLM represents one of the most critical building blocks in modern AI infrastructure.

If your organization uses AI agents, MCP servers, or LLM orchestration tools, you need to read this now. The attack was discovered within hours, but the implications will reverberate through the AI security landscape for months to come.

What Is LiteLLM and Why Does This Matter?

LiteLLM has become the de facto standard for AI application development. It provides a unified interface to call over 100 LLM APIs - including OpenAI, Anthropic, Bedrock, and VertexAI - using a single, standardized format. The library handles automatic fallbacks, retries, cost tracking, and provider switching across the entire AI ecosystem.

The credential density in LiteLLM deployments makes it an attacker's dream target:

When LiteLLM is compromised, attackers don't just get access to one system. They get the master keys to your entire AI infrastructure.

💡 Key Insight: LiteLLM's 95 million monthly downloads make it one of the most widely distributed Python packages in the AI ecosystem. The blast radius of this compromise extends far beyond direct installations - the library is pulled in automatically by AI development tools, MCP plugins, and agent frameworks.

The Attack Timeline: How TeamPCP Operates

TeamPCP didn't target LiteLLM in isolation. This attack was part of a coordinated campaign against the most trusted tools in cloud-native security:

Date Target Impact
March 1, 2026 Xygeni GitHub Action Initial supply chain compromise
March 19, 2026 Aqua Trivy Scanner CI/CD pipeline compromise
March 21, 2026 Checkmarx/KICS GitHub Action Security tool backdoor
March 22, 2026 Aqua Security Repositories 44 internal repositories defaced
March 23, 2026 Checkmarx VS Code Extensions 36,000+ IDE installations affected
March 24, 2026 LiteLLM PyPI Package 480M+ download base compromised

The pattern is clear: TeamPCP is systematically targeting the security tools and AI infrastructure that enterprises rely on most. By compromising the tools that developers trust, they create a cascade of downstream compromises that are nearly impossible to detect until it's too late.

How the LiteLLM Compromise Worked

Stage 0: Account Takeover and Initial Access

The compromise began with the GitHub account of LiteLLM's co-founder and CEO, Krish Dholakia. On March 23, 2026, at approximately 15:30 UTC, a malicious branch was created and immediately deleted in both the litellm and litellm-skills repositories. This branch contained a malicious workflow file designed to exfiltrate secrets from CI/CD runners.

Workflow execution metrics confirmed that the malicious code ran on GitHub's infrastructure, giving attackers access to environment variables containing sensitive credentials. This initial foothold provided the access needed to publish directly to PyPI.

Stage 1: Malicious Package Publication

On March 24, 2026, at 10:52 UTC, LiteLLM version 1.82.8 was published to PyPI. No corresponding tag or release exists on the GitHub repository - a clear indicator that the normal release workflow was bypassed. Version 1.82.7 was also compromised, with malicious code injected into litellm/proxy/proxy_server.py.

The attack was discovered by researchers at FutureSearch when the package was pulled in as a transitive dependency by an MCP plugin running inside Cursor. This detail is critical: the victim never ran pip install litellm. It was pulled in automatically by their AI development tooling.

Stage 2: The Three-Stage Payload

The malware operates as a sophisticated three-stage attack designed for maximum credential harvesting and persistence:

Injection Vectors:

Version 1.82.7 injects an obfuscated base64 payload into litellm/proxy/proxy_server.py at line 128. The payload executes at import time, meaning any process that imports the LiteLLM proxy triggers the malware. The injected code is triple-nested: base64 in proxy_server.py decodes to an orchestrator, which decodes a second base64 blob containing the actual harvester.

Version 1.82.8 adds a second, more aggressive vector: a .pth file called litellm_init.pth (34,628 bytes). Python's .pth files are processed by the site module during interpreter startup. They don't need an import statement. They don't need your code to reference LiteLLM. If the package is installed in your environment, the .pth file executes on every single Python process invocation.

Opening a Python REPL? It runs. Running a Django management command? It runs. Your CI pipeline executing pytest? It runs.

Credential Harvesting:

Once executing, the payload systematically sweeps the host for everything of value:

The collected data is encrypted with a hardcoded 4096-bit RSA public key using AES-256-CBC, bundled into a tar archive named tpcp.tar.gz, and exfiltrated via HTTP POST to models.litellm[.]cloud - a domain designed to look like legitimate LiteLLM infrastructure.

Kubernetes Lateral Movement:

If the malware detects a Kubernetes service account token on the host (present by default on every pod unless explicitly disabled), it escalates further:

⚠️ Critical Warning: Version 1.82.8's .pth file creates an exponential fork bomb when spawning child processes. This bug actually led to the initial discovery when a developer's machine ran out of RAM and crashed. Without this bug, the compromise might have gone undetected for days or weeks.

The Discovery: How the Attack Was Caught

The attack was discovered through a fortunate accident. Callum McMahon, a research scientist at FutureSearch, loaded the malicious payload and it caused havoc on his local machine. The .pth file's fork bomb bug caused his system to run out of memory, triggering an investigation that revealed the compromise.

Sonatype researchers quickly confirmed the malicious nature of the packages, noting that "given the package's place in the AI stack, cybercriminals are looking to take advantage of enterprises leveraging open source to rapidly develop and deploy AI applications."

The PyPI security team moved quickly to quarantine the affected project, reducing the potential impact. But for organizations that had already installed the compromised versions, the damage may already be done.

Immediate Actions: What You Need to Do Right Now

If your organization uses LiteLLM, take these steps immediately:

1. Check Your Versions

Run this command across all environments:

pip show litellm

If you're on versions 1.82.7 or 1.82.8, assume compromise and proceed with full incident response.

2. Remove the Malicious Package

pip uninstall litellm
pip install litellm==1.82.6

The last known-clean version is 1.82.6.

3. Check for Persistence Artifacts

Look for these indicators of compromise:

# Check for the systemd backdoor
ls -la ~/.config/sysmon/
cat ~/.config/sysmon/sysmon.py

# Check for unauthorized Kubernetes pods
kubectl get pods -n kube-system | grep alpine

# Check for suspicious .pth files
find /usr -name "litellm_init.pth" 2>/dev/null

4. Audit Kubernetes Clusters

If LiteLLM was deployed in a Kubernetes environment:

# Check for unauthorized pods
kubectl get pods --all-namespaces -o wide

# Check for privileged pods
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged == true) | .metadata.name'

# Review secret access logs
kubectl logs -n kube-system deployment/kube-apiserver | grep -i secret

5. Rotate All Credentials

This is non-negotiable. Rotate every credential that was accessible from the compromised machine:

🔑 Key Takeaway: The malware encrypted exfiltrated data with a hardcoded RSA key, meaning TeamPCP has access to everything the malware harvested. Assume all credentials are compromised and rotate them immediately.

The Bigger Picture: Why AI Tooling Is the New Target

This attack reveals a fundamental shift in the threat landscape. AI tooling has become the fattest, most credential-rich target in enterprise infrastructure:

Credential Density: AI development environments contain the highest concentration of valuable credentials in modern infrastructure. A single developer laptop might have:

Trust Relationships: AI tools like LiteLLM sit at the intersection of multiple trust boundaries. They need access to everything - your code, your data, your cloud infrastructure, your AI models. Compromising these tools gives attackers a privileged position that would take months to achieve through traditional methods.

Transitive Dependencies: Modern AI development relies on complex dependency chains. The LiteLLM compromise was discovered when it was pulled in automatically by an MCP plugin running inside Cursor. Developers often don't even know they're using LiteLLM - it's just a transitive dependency of something else.

Supply Chain Complexity: The AI ecosystem moves fast. New tools, frameworks, and libraries appear weekly. Security teams can't keep up with the velocity of change, creating gaps that attackers exploit.

Defense Strategies: Protecting Your AI Infrastructure

Layer 1: Dependency Management

Pin Your Dependencies

Never use floating versions in production:

# Bad - accepts any version
litellm>=1.80.0

# Good - exact version only
litellm==1.82.6

Use Lock Files

Generate and commit lock files to ensure reproducible builds:

pip freeze > requirements.lock
pip install -r requirements.lock

Private Package Repositories

Mirror critical dependencies to a private repository where you control updates:

# Use a private PyPI mirror
pip install --index-url https://pypi.yourcompany.com/simple litellm

Layer 2: Runtime Monitoring

Behavioral Detection

Monitor for suspicious activity in Python processes:

Container Security

Run AI workloads in containers with minimal privileges:

# Don't run as root
USER 1000

# Read-only filesystem where possible
read_only: true

# Drop all capabilities
cap_drop:
  - ALL

Layer 3: Network Segmentation

Microsegmentation

Isolate AI tooling from sensitive infrastructure:

Zero Trust Architecture

Assume compromise and verify everything:

Layer 4: Supply Chain Security

Software Composition Analysis (SCA)

Use tools to monitor your dependency tree for known issues:

Vendor Security Assessment

Before adopting new AI tools:

Layer 5: Incident Response

Assume Breach Posture

Design your AI infrastructure assuming compromise:

Detection Engineering

Build detection rules for AI-specific threats:

FAQ: LiteLLM Supply Chain Attack

How do I know if I was affected by the LiteLLM compromise?

Check your installed version with pip show litellm. If you're on versions 1.82.7 or 1.82.8, assume compromise. Also check your pip logs and CI/CD history for installations on March 24, 2026. Look for persistence artifacts in ~/.config/sysmon/ and unauthorized pods in your Kubernetes clusters.

What credentials were targeted by the malware?

The malware harvested SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes configs, LLM API keys (OpenAI, Anthropic, HuggingFace), environment variables, .env files, .gitconfig, shell history, cryptocurrency wallets, and database connection strings. Essentially anything of value on the compromised system.

How did TeamPCP gain access to publish to PyPI?

The attack began with a GitHub account compromise of LiteLLM's co-founder. Malicious workflow files were used to exfiltrate CI/CD credentials, which were then used to publish directly to PyPI, bypassing the normal release workflow.

What is a .pth file and why is it dangerous?

Python .pth files are processed during interpreter startup by the site module. They execute automatically without requiring an import statement. The malicious litellm_init.pth file executed on every Python process invocation, making it particularly dangerous and difficult to detect.

Should I stop using LiteLLM?

Not necessarily. LiteLLM is a valuable tool that has been secured after the incident. The compromised versions have been removed from PyPI. Follow security best practices: pin to known-good versions (1.82.6 or earlier), monitor for security advisories, and implement the defense strategies outlined in this post.

How can I prevent similar supply chain attacks?

Implement defense in depth: pin dependencies to exact versions, use private package repositories, monitor for suspicious runtime behavior, segment your networks, use software composition analysis tools, and maintain an assume-breach posture with automated incident response capabilities.

What is TeamPCP and what do they want?

TeamPCP is a cybercriminal group that emerged in late 2025. They systematically target cloud-native and AI infrastructure tools. Their motivations appear to be credential theft for financial gain, with evidence of selling access to compromised environments and exfiltrated data on underground forums.

How long was the malicious package available on PyPI?

The malicious versions were published on March 24, 2026, and discovered within hours. The PyPI security team quarantined the affected project quickly, but the exact window of exposure depends on when individual organizations installed or updated the package.

What should I do if I find persistence artifacts on my systems?

Treat it as a full security incident: isolate affected systems, preserve forensic evidence, rotate all credentials from the compromised environment, audit Kubernetes clusters for unauthorized pods, rebuild systems from known-clean state, and conduct a thorough investigation to understand the scope of compromise.

Are other AI tools at risk of similar attacks?

Yes. Any widely-used AI tool with access to credentials is a potential target. The AI ecosystem's rapid growth, complex dependency chains, and high credential density make it particularly attractive to attackers. Apply the defense strategies in this post to all AI tooling in your environment.

The Future of AI Supply Chain Security

The LiteLLM compromise is not an isolated incident. It's a harbinger of what's to come as AI tooling becomes central to enterprise infrastructure. Security teams must adapt to a new reality where:

AI Tools Are Critical Infrastructure: The libraries and frameworks that power AI development are as critical as your operating system or cloud provider. They require the same level of security scrutiny and protection.

Supply Chain Attacks Are the New Normal: Attackers have realized that compromising upstream dependencies is far more efficient than targeting individual organizations. The return on investment for supply chain attacks is massive - one compromise can affect thousands of downstream victims.

Trust Must Be Continuously Verified: The traditional model of trusting packages from official repositories is broken. Every dependency must be verified, monitored, and treated as potentially malicious until proven otherwise.

Security Must Move Left and Right: Securing AI infrastructure requires both pre-deployment controls (dependency scanning, vendor assessment) and runtime protection (behavioral monitoring, network segmentation). One without the other leaves dangerous gaps.

Conclusion: The Credential-Rich Target

The LiteLLM supply chain attack demonstrates a fundamental truth about AI infrastructure: it's the most credential-rich target in modern computing. AI tools need access to everything - your data, your cloud, your models, your secrets. This makes them incredibly powerful for legitimate use cases and incredibly valuable for attackers.

TeamPCP understood this. They didn't target LiteLLM because it was vulnerable - they targeted it because it was valuable. The library's position in the AI stack gave them access to the master keys of thousands of organizations' AI infrastructure.

The defense strategies in this post aren't theoretical. They're the minimum viable security for any organization building with AI. Dependency management, runtime monitoring, network segmentation, supply chain security, and incident response capabilities aren't optional extras - they're essential infrastructure.

Your AI tooling is your most powerful asset and your biggest security risk. Treat it accordingly.

Check your versions. Rotate your credentials. Monitor your infrastructure. The next attack is already being planned.

Stay ahead of emerging threats. Subscribe to the Hexon.bot newsletter for weekly AI security insights.

External Sources