LiteLLM Supply Chain Attack: Protect Your AI Stack

What Happened: The March 24 Attack

The incident was disclosed publicly on March 24, 2026 after security researchers identified anomalous network traffic patterns originating from environments running LiteLLM. Investigation traced the behavior to malicious PyPI packages published as part of the TeamPCP campaign — a coordinated operation targeting AI infrastructure tooling across multiple open-source projects.

The malicious packages were not modifications to LiteLLM's official codebase. LiteLLM's core package published through its official maintainers was not itself compromised. The attack worked by publishing packages with names designed to be confused with legitimate LiteLLM plugins and optional dependencies — a technique combining typosquatting, dependency confusion, and in some cases targeted advertising of the fake packages in AI developer communities.

The attack exploited a structural vulnerability in how AI developers consume open-source tooling: the LiteLLM ecosystem has grown to include many optional plugins and provider-specific packages, and developers routinely install these from PyPI based on documentation references without verifying package provenance. TeamPCP understood this behavior and designed its campaign specifically to exploit it.

TeamPCP Campaign and Attack Vector

TeamPCP is a financially motivated threat actor group that has been observed targeting developer tooling ecosystems across multiple programming languages since 2024. The March 2026 LiteLLM campaign represents their most significant operation to date in terms of affected download volume and the sensitivity of the credentials targeted. The group operates with a level of operational sophistication that distinguishes them from opportunistic typosquatters.

The payload's operational security was notable. It used HTTPS with valid certificates for exfiltration traffic, mimicking normal API provider traffic patterns. It added no visible error output, no anomalous CPU or memory usage, and no behavioral signals that would trigger standard application monitoring. Detection required network traffic analysis looking for unexpected destination IPs in the AI provider traffic pattern — a level of inspection most organizations do not apply to their AI service deployments.

Scope of Exposure: 97M Monthly Downloads

LiteLLM's 97 million monthly downloads reflect its position as the de facto standard for LLM provider abstraction in Python AI applications. That download volume does not mean 97 million organizations were affected — a significant portion of downloads are CI/CD pipeline reinstallations of the same few thousand production deployments. But the scale indicates the breadth of the potential attack surface.

The incident highlights a structural problem in AI infrastructure security: LLM proxies like LiteLLM occupy an extraordinarily privileged position in the AI stack. They sit between applications and model providers, routing all traffic and holding credentials for multiple providers simultaneously. A compromise at this layer is worse than an application-level compromise because it affects every model interaction across every application routed through the proxy. This is precisely why AI supply chain attacks are increasingly attractive to sophisticated threat actors, as explored in our analysis of shadow AI across 76% of organizations — where unmonitored AI tooling creates exactly the visibility gaps attackers exploit.

What Data Was Compromised

Understanding what the malicious payload targeted helps organizations prioritize their incident response and assess the full scope of potential business impact beyond the immediate credential rotation requirement.

Organizations in regulated industries — healthcare, finance, legal — should assess whether the intercepted prompt content constitutes a reportable breach under applicable regulations (HIPAA, GDPR, CCPA, SOX). If LiteLLM was processing patient information, financial data, or other regulated categories, legal and compliance teams should be engaged immediately for breach notification assessment.

Immediate Detection and Audit Steps

Before rotating credentials and hardening your deployment, complete a forensic audit to establish whether and how your environment was affected. The order matters: audit first to understand scope, then rotate to remediate, then harden to prevent recurrence.

If your deployment runs in containers, pull the image manifest and review the layer history for unexpected package installations. For Kubernetes deployments, review admission controller logs for the affected time window. Check your CI/CD pipeline logs for any pip install steps that may have pulled packages not in your pinned requirements file.

API Key Rotation and Credential Hygiene

Credential rotation is not optional for any organization that ran LiteLLM during the affected window without confirmed clean audit results. The rotation sequence matters: create new keys before deactivating old ones to avoid service interruption, update all deployment environments with new keys, then deactivate and delete old keys.

After rotation, implement secrets management as a structural improvement rather than continuing to pass credentials as environment variables. HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault all support dynamic secret issuance — generating short-lived credentials on demand rather than storing long-lived API keys. For AI provider keys specifically, use the minimum permissions scoping each provider allows (read-only keys where your use case permits, rate-limited keys for development environments).

Dependency Pinning and Verification

The root cause enabler of this attack was the combination of loose version specifications and public PyPI access without hash verification. Addressing both is required to prevent recurrence. These are not aspirational security improvements — they are standard software supply chain controls that should be in place for any production AI infrastructure.

For teams using Docker-based LiteLLM deployments, pin the base image to a specific digest (not just a tag) and use multi-stage builds that install dependencies in a verified build stage and copy only the final artifacts to the runtime stage. This prevents the runtime container from having pip access and eliminates the attack surface for runtime package installation.

Hardening Your LiteLLM Deployment

Beyond package security, the LiteLLM deployment architecture itself can be hardened to limit the impact of any future compromise. These controls reduce the blast radius of a supply chain attack from catastrophic (all credentials exfiltrated, all traffic intercepted) to contained (limited blast radius, rapid detection).

Broader AI Supply Chain Risk Landscape

The LiteLLM attack is not an isolated incident. It is a data point in a clear trend: as AI infrastructure tooling matures and becomes more widely deployed, it becomes a more attractive supply chain target. The economics are compelling for attackers — a single compromise of a widely-used AI proxy library can yield credentials for multiple AI providers across thousands of organizations simultaneously.

AI infrastructure has several properties that make it a particularly high-value supply chain target compared to traditional software dependencies. LLM proxies and SDKs hold credentials for multiple expensive API services. AI requests often contain sensitive data from users or proprietary business logic in system prompts. The AI tooling ecosystem is relatively young, with security practices lagging behind adoption rates. And many AI deployments run with broad permissions justified by the “it's just a developer tool” framing that has not caught up with production usage realities.

The good news is that the defensive controls are well-understood. Software supply chain security has been a mature discipline in other contexts for years, and the same controls — dependency pinning, hash verification, private registries, SBOM generation, network egress filtering — apply directly to AI infrastructure. The gap is not knowledge but implementation: most AI teams have not yet applied these controls to their AI tooling with the same rigor they apply to their application infrastructure. The LiteLLM incident makes the cost of that gap concrete. For organizations assessing their broader AI security posture, our service page on AI and digital transformation covers how to build AI capabilities on a secure foundation.