Le 24 mars 2026, le package Python litellm, l'un des outils les plus utilisés de l'écosystème LLM avec plus de 3 millions de téléchargements par jour, a été compromis directement sur PyPI. L'attaque, attribuée au groupe TeamPCP, compte parmi les plus sophistiquées jamais observées dans l'univers de l'IA open source.
Dans cet article, nous revenons sur ce qui s'est passé, sur ce que cela implique et sur les pratiques de sécurité qui protègent une stack IA.
Ce qui s'est passé
Le 24 mars, entre 10h39 et 16h00 UTC, deux versions malveillantes de litellm ont été publiées sur PyPI : les versions 1.82.7 et 1.82.8. Elles contenaient une charge malveillante en plusieurs étapes, d'une sophistication extrême.
L'attaque a commencé par la compromission de Trivy, un scanner de sécurité très répandu dans les pipelines CI/CD. Les attaquants ont exploité une GitHub Action du pipeline CI/CD de LiteLLM pour dérober les identifiants PyPI du projet. Une fois ces identifiants en main, TeamPCP a publié directement des versions du package contenant une backdoor.
Une charge malveillante en trois étapes
Le malware embarqué dans les versions compromises n'avait rien d'un simple script malveillant. Il s'agissait d'une attaque en trois étapes, conçue pour maximiser l'exfiltration de données et la persistance.
Étape 1 : vol d'identifiants à grande échelle. Le malware scannait puis exfiltrait les clés SSH, les identifiants cloud (AWS, GCP, Azure), les secrets Kubernetes, les portefeuilles de cryptomonnaies et tous les fichiers .env présents sur la machine. Autrement dit, tout ce qui donne accès à des systèmes sensibles.
Étape 2 : mouvement latéral dans Kubernetes. Une fois les secrets Kubernetes récupérés, le malware déployait automatiquement des pods privilégiés sur chaque nœud du cluster. Objectif : étendre l'attaque à toute l'infrastructure.
Étape 3 : backdoor persistante. Un service systemd malveillant (sysmon.service) était installé et configuré pour interroger régulièrement un serveur de commande (checkmarx[.]zone/raw) afin de télécharger et d'exécuter des binaires supplémentaires. Même après la mise à jour du package, la backdoor restait active.
Qui est concerné ?
Toute personne ou organisation ayant exécuté pip install litellm ou pip install --upgrade litellm le 24 mars entre 10h39 et 16h00 UTC sans version épinglée est potentiellement compromise. Une dépendance épinglée sur 1.82.7 ou 1.82.8 l'est aussi. Avec 3 millions de téléchargements quotidiens, même une fenêtre de quelques heures représente des dizaines de milliers d'installations potentiellement touchées.
En revanche, les utilisateurs de l'image Docker officielle LiteLLM Proxy n'ont pas été touchés : cette image utilise des dépendances verrouillées dans un fichier requirements.txt.
Ce qui protège une stack qui embarque LiteLLM
Une stack peut embarquer LiteLLM sans avoir été exposée à cette attaque. Cinq pratiques font la différence.
Des versions de packages strictement épinglées
Chaque dépendance est épinglée à une version exacte dans les fichiers de configuration. On ne lance jamais pip install litellm sans préciser une version exacte et vérifiée. Résultat : même si une version malveillante est publiée sur PyPI, le pipeline ne la récupère jamais automatiquement.
Un audit de sécurité à chaque release
Avant chaque déploiement, un audit complet des dépendances : vérification des hashes des packages, détection des anomalies dans les mises à jour, recoupement avec les bases de vulnérabilités connues. Une mise à jour inattendue déclenche alors une alerte immédiate.
Des builds reproductibles et auditables
Des builds déterministes : pour une même configuration, le résultat est toujours identique. Toute altération de la chaîne de build se détecte, et ce qui est testé est exactement ce qui est déployé.
Aucune mise à jour automatique en production
Beaucoup d'organisations utilisent des plages de versions (>=1.82.0) ou des mises à jour automatiques. La règle inverse : aucune dépendance mise à jour en production sans validation manuelle préalable. C'est cette discipline qui protège des attaques supply chain.
L'isolation des environnements
Chaque composant est isolé. Même si un package compromis était installé, une séparation stricte des privilèges et des réseaux limite le rayon d'impact.
Ce qu'il faut retenir
Cette attaque n'est pas un incident isolé. Elle signale une tendance qui ne fera que s'accélérer. L'écosystème IA/LLM est devenu une cible de choix pour les attaquants, et les attaques supply chain en sont le vecteur le plus efficace.
Voici les pratiques que nous recommandons à toute organisation qui déploie des agents IA en production.
Épinglez systématiquement vos dépendances. Utilisez des versions exactes, pas des plages. Vérifiez les hashes. Ne faites jamais confiance à « la dernière version ».
Auditez vos dépendances avant chaque déploiement. Utilisez des outils comme pip-audit, Snyk ou Dependabot, sans vous reposer uniquement sur eux. Une revue manuelle des changements critiques reste indispensable.
Sécurisez vos pipelines CI/CD. L'attaque contre LiteLLM a commencé par la compromission de Trivy dans le pipeline CI/CD. Vos outils de sécurité peuvent eux-mêmes devenir le vecteur d'attaque. Appliquez le principe du moindre privilège à chaque étape de votre pipeline.
Isolez vos environnements. Ne donnez pas à vos agents IA un accès illimité au réseau ou aux secrets. Utilisez des sandboxes, des politiques réseau et une séparation stricte des rôles.
Surveillez en continu. Un package compromis peut avoir des effets persistants (comme la backdoor systemd de cette attaque). La détection en temps réel des comportements anormaux est essentielle.
Conclusion
L'open source est formidable, et LiteLLM est un excellent outil. Mais déployer des composants open source en production sans gouvernance, c'est jouer à la roulette russe avec vos données et celles de vos clients. La question n'est pas de savoir si une attaque supply chain touchera votre stack IA, mais quand.
Sources :
- LiteLLM, « Security Update: Suspected Supply Chain Incident »
- Snyk, « How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM »
- Datadog Security Labs, « LiteLLM Compromised on PyPI: Tracing the March 2026 TeamPCP Supply Chain Campaign »
- Kaspersky, « Trojanization of Trivy, Checkmarx, and LiteLLM Solutions »
- Sonatype, « Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer »
