L'IA agentique d'entreprise.
À la française.
L'essentiel: On March 24, 2026, two malicious litellm versions (1.82.7, 1.82.8) shipped on PyPI from threat group TeamPCP. The multi-stage payload exfiltrated env vars + API keys. Idun cloud.idunplatform.com was not affected — we pin all dependencies by SHA, scan SBOMs in CI, and isolate LLM secrets in a per-deployment vault. Upgrade to 1.82.9 immediately if you use litellm.
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.
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.
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.
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.
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.
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.
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.