--- title: "LiteLLM Supply Chain Attack: Why Idun Platform Users Are Not Affected" slug: "litellm-supply-chain-attack" date: "2026-03-26" dateModified: "2026-03-26" author: "Geoffrey Harrazi" description: "On March 24, 2026, litellm was compromised on PyPI by TeamPCP. Here is what happened, why it matters, and why Idun Platform users were not affected." tags: ["security", "supply-chain", "litellm", "open-source"] image: "/og-image.png" published: true --- On March 24, 2026, the Python package **litellm** -- one of the most widely used tools in the LLM ecosystem with over 3 million downloads per day -- was compromised directly on PyPI. The attack, attributed to the threat actor group **TeamPCP**, is one of the most sophisticated ever observed in the open source AI world. At Idun Group, our platform **cloud.idunplatform.com** was not impacted. In this article, we break down what happened, why it matters, and what security practices kept us protected. ## What Happened Between **10:39 AM and 4:00 PM UTC** on March 24, two malicious versions of litellm were published on PyPI: versions **1.82.7** and **1.82.8**. These versions contained an extremely sophisticated multi-stage malware payload. The attack began with the compromise of **Trivy**, a popular security scanner used in CI/CD pipelines. The attackers exploited a GitHub Action in LiteLLM's CI/CD pipeline to steal the project's PyPI credentials. Once in possession of those credentials, TeamPCP directly published backdoored versions of the package. ## A Three-Stage Payload The malware embedded in the compromised versions was not a simple malicious script. It was a three-stage attack designed to maximize data exfiltration and persistence. **Stage 1: Large-scale credential theft.** The malware scanned and exfiltrated SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes secrets, cryptocurrency wallets, and all `.env` files present on the machine. In other words, everything that provides access to sensitive systems. **Stage 2: Kubernetes lateral movement.** Once Kubernetes secrets were harvested, the malware automatically deployed privileged pods to every node in the cluster. The goal: extend the attack across the entire infrastructure. **Stage 3: Persistent backdoor.** A malicious systemd service (`sysmon.service`) was installed and configured to regularly poll a command server (`checkmarx[.]zone/raw`) to download and execute additional binaries. Even after updating the package, the backdoor remained active. ## Who Is Affected? Any person or organization that ran `pip install litellm` or `pip install --upgrade litellm` on March 24 between 10:39 AM and 4:00 PM UTC **without a pinned version** is potentially compromised. With 3 million daily downloads, even a window of a few hours represents tens of thousands of potentially affected installations. However, users of the official LiteLLM Proxy Docker image were not affected, as that image uses locked dependencies in a `requirements.txt` file. ## Why Idun Platform Is Not Affected Our platform cloud.idunplatform.com uses LiteLLM as an LLM proxy in our stack. But our users were never exposed to this attack. Here is why. ### Strictly Pinned Package Versions Every dependency in our platform is pinned to an exact version in our configuration files. We never run `pip install litellm` without specifying a precise, verified version. This means that even if a malicious version is published on PyPI, our pipeline never pulls it automatically. ### Security Audit at Every Release Before every deployment, we run a complete audit of our dependencies. This includes verifying package hashes, detecting anomalies in updates, and cross-referencing against known vulnerability databases. An unexpected update would have triggered an immediate alert. ### Reproducible and Auditable Builds Our builds are deterministic. For the same configuration, the result is always identical. This allows us to detect any tampering in the build chain and ensures that what is tested is exactly what gets deployed. ### No Automatic Updates in Production Unlike many organizations that use version ranges (`>=1.82.0`) or automatic updates, we never update a dependency in production without prior manual validation. This is a fundamental discipline that protects us from supply chain attacks. ### Environment Isolation Every component of our platform is isolated. Even in the hypothetical scenario where a compromised package had been installed, our platform's architecture limits the blast radius through strict separation of privileges and networks. ## Key Takeaways This attack is not an isolated incident. It signals a trend that will only accelerate. The AI/LLM ecosystem has become a prime target for attackers, and supply chain attacks are the most effective vector. Here are the practices we recommend to any organization deploying AI agents in production. **Pin your dependencies systematically.** Use exact versions, not ranges. Verify hashes. Never trust "the latest version." **Audit your dependencies before every deployment.** Use tools like `pip-audit`, Snyk, or Dependabot, but do not rely on them alone. A manual review of critical changes remains indispensable. **Secure your CI/CD pipelines.** The LiteLLM attack started with a compromise of Trivy in the CI/CD pipeline. Your security tools themselves can become the attack vector. Apply the principle of least privilege at every stage of your pipeline. **Isolate your environments.** Do not give your AI agents unrestricted access to the network or secrets. Use sandboxes, network policies, and strict role separation. **Monitor continuously.** A compromised package can have persistent effects (like the systemd backdoor in this attack). Real-time detection of abnormal behavior is essential. ## Conclusion Open source is fantastic. LiteLLM is an excellent tool that we use ourselves. But deploying open source components in production without governance is playing Russian roulette with your data and your customers' data. This is exactly why we built Idun Platform: an open source AI agent deployment platform that takes security, observability, and governance seriously. Because the question is not **if** a supply chain attack will hit your AI stack, but **when**. Secure your deployments today at [cloud.idunplatform.com](https://cloud.idunplatform.com). --- *Sources:* - [LiteLLM - Security Update: Suspected Supply Chain Incident](https://docs.litellm.ai/blog/security-update-march-2026) - [Snyk - How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM](https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/) - [Datadog Security Labs - LiteLLM Compromised on PyPI: Tracing the March 2026 TeamPCP Supply Chain Campaign](https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/) - [Kaspersky - Trojanization of Trivy, Checkmarx, and LiteLLM Solutions](https://www.kaspersky.com/blog/critical-supply-chain-attack-trivy-litellm-checkmarx-teampcp/55510/) - [Sonatype - Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer](https://www.sonatype.com/blog/compromised-litellm-pypi-package-delivers-multi-stage-credential-stealer)