What the LiteLLM Supply Chain Attack Means for Enterprise AI

On March 24, 2026, two versions of LiteLLM, the most widely used open-source LLM proxy in the Python ecosystem, were pulled from the Python Package Index after a supply chain attack injected credential-stealing malware into the package. The attack was traced to TeamPCP, a threat actor group conducting a coordinated multi-week campaign targeting security tools and AI infrastructure.

LiteLLM is downloaded approximately 3.4 million times per day. According to research from Wiz, it is present in 36 percent of all cloud environments. The entire package has been quarantined on PyPI. This is not a patch-and-move-on situation. This is a structural failure in how enterprises adopt AI infrastructure.

**The Attack Chain**

The LiteLLM compromise did not occur in isolation. It was the third strike in a cascading supply chain campaign.

On March 19, TeamPCP compromised Aqua Security’s Trivy vulnerability scanner by rewriting Git tags in the trivy-action GitHub Action repository. Because many CI/CD pipelines reference version tags rather than pinned commits, the malicious code was pulled into builds automatically without any visible change to the pipeline configuration.

On March 23, the same infrastructure was used to compromise Checkmarx KICS GitHub Actions.

On March 24, LiteLLM’s CI/CD pipeline, which used an unpinned version of Trivy, ran the compromised scanner. The attacker exfiltrated LiteLLM’s PYPI\_PUBLISH token from the GitHub Actions runner environment and used it to publish malicious versions 1.82.7 and 1.82.8 directly to PyPI.

The malicious packages contained a three-stage payload. First, a credential harvester scanned the system for SSH keys, cloud credentials, Kubernetes secrets, environment files, databases, and crypto wallets. Second, tools for lateral movement deployed privileged pods across Kubernetes nodes. Third, a persistent systemd backdoor maintained long-term access while blending in with normal system processes. Version 1.82.8 was especially dangerous: it installed a .pth file that executed the credential stealer every time the Python interpreter started, regardless of whether LiteLLM was imported.

**This Was Not an Anomaly**

LiteLLM had 17 or more documented CVEs before the March 2026 incident, including SSRF vulnerabilities, authentication bypasses, and server-side template injection flaws. The Trivy compromise was publicly disclosed on March 19, five days before the LiteLLM attack. Credentials were not rotated. When the GitHub vulnerability report was filed, it was initially closed as “not planned” and then flooded with approximately 170 AI-generated spam comments, likely from other accounts compromised in the same campaign.

This is not a story about one bad day. This is a story about structural decisions compounding over time until a sophisticated threat actor exploited them.

**Why Architecture Matters More Than Features**

The LiteLLM attack worked because it exploited trust in the delivery mechanism. You trust PyPI. You trust your CI/CD pipeline. You trust the maintainer’s credentials. Remove any one of those trust assumptions and the attack path collapses.

This is why the deployment model is the security model. If your AI governance layer is a Python library pulled from a public registry at build time, every vulnerability in that supply chain is your vulnerability. If your AI governance layer is a software appliance delivered to your data center, tested on your hardware, deployed inside your network perimeter, and updated through your change management process, the attack path described above does not apply. Not partially. Not mostly. Does not apply.

This distinction is not about features. Both approaches can route prompts to models. Both can cache responses. Both can log interactions. The difference is where the software lives, how it gets there, and who controls it. For regulated industries in financial services, healthcare, and defense, that difference is the only one that matters.

**What Enterprises Should Do Now**

If your organization used LiteLLM versions 1.82.7 or 1.82.8, assume full credential compromise for every system where it was installed and all systems reachable from those machines. Rotate all credentials. Audit pip caches and Docker image layer histories.

Beyond the immediate incident response, every enterprise should be asking three questions about their AI infrastructure:

First, where does our AI governance layer actually run? If the answer is “wherever a developer installed it,” that is not governance.

Second, what is our supply chain exposure? How many AI dependencies have we never formally evaluated?

Third, can we demonstrate to a regulator, auditor, or board that we control our AI infrastructure end-to-end?

If the answers to those questions make you uncomfortable, that discomfort is the beginning of a real AI governance conversation.

**The Path Forward**

At APERION, we built SmartFlow on the conviction that regulated enterprises need to own their AI infrastructure. On-premises. Kubernetes-native. Identity-aware. Policy-enforced. Audit-trailed. Deployed behind the firewall with no dependency on public package registries. That architectural decision, made years before anyone knew the name TeamPCP, is the reason SmartFlow was unaffected by the LiteLLM supply chain attack.

Tomorrow we are releasing the SmartFlow SDK, a Python library that gives every developer an immediate path from evaluation to production-grade AI governance. We have also published a migration whitepaper for organizations transitioning from OpenRouter and other OpenAI-compatible proxies to SmartFlow.

The LiteLLM incident did not create our market. It proved our market exists.