Le piratage de LiteLLM s’alourdit : une fuite géante de secrets remet les équipes IA en alerte

En mars 2026, LiteLLM — une bibliothèque Python très utilisée pour parler à plusieurs fournisseurs de modèles d’IA avec une interface unique compatible OpenAI — a confirmé une compromission de sa publication sur PyPI (le registre public de paquets Python). L’éditeur indique que les versions 1.82.7 et 1.82.8 ont été publiées sans autorisation, probablement via un compte de maintenance compromis, dans une fenêtre allant du 24 mars 2026 à 10:39 UTC à 16:00 UTC. Les images Docker officielles, LiteLLM Cloud, les installations depuis GitHub et les versions 1.82.6 ou antérieures n’étaient pas concernées. (docs.litellm.com.cn)

Ce que faisait réellement le package piégé

Le code malveillant ne se contentait pas de casser un build. Selon l’avis de sécurité LiteLLM, il scannait les variables d’environnement (les secrets injectés dans les processus), les clés SSH (accès aux serveurs et dépôts), les identifiants AWS, GCP et Azure (clouds publics), les jetons Kubernetes (orchestrateur de conteneurs), ainsi que des mots de passe de base de données, puis exfiltrait ces données vers models.litellm.cloud, un domaine contrôlé par l’attaquant et explicitement signalé comme non légitime. Un rapport technique tiers ajoute que la version 1.82.8 utilisait un fichier .pth — un mécanisme Python exécuté au démarrage de l’interpréteur — ce qui permettait d’exécuter le malware sans même importer LiteLLM dans le code applicatif. (docs.litellm.com.cn)

Pourquoi cette affaire concerne directement les équipes qui utilisent des agents IA

LiteLLM est présent dans des frameworks d’agents IA (outils qui enchaînent automatiquement modèle, appels d’outils et exécution), des serveurs MCP (Model Context Protocol, protocole pour brancher des outils et des sources de données à un modèle), des passerelles de production et des outils d’orchestration. L’avis LiteLLM précise qu’une équipe pouvait être touchée non seulement par un pip install litellm, mais aussi via une dépendance transitive (un paquet installé indirectement par un autre). Palo Alto Unit 42 relie d’ailleurs l’incident à une campagne plus large de TeamPCP contre des outils de sécurité et d’infrastructure, en recommandant explicitement le pinning (verrouillage précis des versions) et un durcissement des politiques CI/CD (intégration et déploiement continus). (docs.litellm.com.cn)

Ce qui change concrètement aujourd’hui

Le nouvel élément, mis en avant par l’article d’Ars Technica, est l’ampleur apparente de la fuite découverte en août 2026 : des chercheurs disent avoir récupéré un corpus d’environ 433 909 fichiers volés, lié à plus de 2 500 organisations touchées. Je présente ce point avec prudence, car je n’ai pas pu ouvrir directement l’article d’Ars Technica à cause d’un blocage d’accès, et je n’ai pas trouvé dans mes recherches une publication primaire équivalente détaillant publiquement ces chiffres au même niveau. En revanche, cette nouvelle ampleur est cohérente avec le fait déjà établi que le malware visait précisément les environnements de développement, de build et de production où s’accumulent les secrets longue durée. ()

Ce que votre équipe devrait faire maintenant

Si vous avez utilisé LiteLLM autour du 24 mars 2026, il faut raisonner comme après une compromission complète de poste ou de runner CI (machine d’automatisation) :

• vérifier la présence des versions 1.82.7 ou 1.82.8 ;
• chercher le fichier litellm_init.pth ;
• rechercher des traces de persistance comme ~/.config/sysmon/sysmon.py et sysmon.service ;
• auditer les sorties réseau vers models.litellm.cloud ;
• révoquer et régénérer les secrets cloud, clés API de modèles, accès Git, SSH et Kubernetes ;
• reconstruire les machines et images affectées depuis une base saine plutôt que “nettoyer à la main”. (docs.litellm.com.cn)

Un contrôle minimal ressemble à ceci :

pip show litellm
find / -name "litellm_init.pth" 2>/dev/null
find / -path "*/sysmon/sysmon.py" 2>/dev/null
find / -path "*/sysmon.service" 2>/dev/null

« Treat any environment that installed 1.82.7 or 1.82.8 as potentially compromised and rotate all secrets. » (blackswan-cybersecurity.com)

La leçon pour les équipes qui industrialisent l’IA est simple : le maillon le plus sensible n’est pas seulement le modèle, mais la couche d’outillage autour de lui — wrappers, passerelles, agents, serveurs MCP, scripts d’installation et workflows CI. Si ces composants ont accès à vos clés OpenAI, Anthropic, AWS ou à votre cluster Kubernetes, alors un simple pip install non verrouillé devient un point d’entrée critique. (docs.litellm.com.cn)