L'essentiel : Le 24 mars 2026, deux versions malveillantes de litellm (1.82.7, 1.82.8) ont été publiées sur PyPI par le groupe TeamPCP. La charge malveillante, en plusieurs étapes, exfiltrait les variables d'environnement et les clés API. La stack de la plateforme open source Idun n'a pas été touchée. Nous épinglons toutes nos dépendances par SHA, scannons les SBOM en CI et isolons les secrets LLM dans un coffre dédié à chaque déploiement. Si vous utilisez litellm, passez immédiatement à la version 1.82.9.
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.
Chez Idun Group, la stack de la plateforme open source Idun n'a pas été impactée. Dans cet article, nous revenons sur ce qui s'est passé, sur ce que cela implique et sur les pratiques de sécurité qui nous ont protégés.
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.
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.
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. 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.
La plateforme open source Idun utilise LiteLLM comme proxy LLM dans sa stack. Ses utilisateurs n'ont pourtant jamais été exposés à cette attaque. Voici pourquoi.
