Installer une dépendance depuis son canal officiel devait être le geste banal du déploiement. Avec LiteLLM 1.107.0, il pouvait suffire à exposer les secrets d’un serveur. Le projet a confirmé que sa chaîne de publication avait été compromise le 21 octobre, diffusant la version 1.107.0 piégée sur PyPI et plusieurs images de conteneurs. Les composants concernés ont été retirés, mais les secrets accessibles aux machines exposées doivent être considérés comme compromis.
LiteLLM sert d’intermédiaire entre des applications et différents fournisseurs de modèles d’IA. L’incident vise ce composant et ses environnements d’exécution, pas tous les utilisateurs de ChatGPT, Claude ou Gemini. Un particulier qui utilise simplement ces services dans son navigateur n’est pas identifié comme victime de cette seule attaque.
La version et l’heure d’installation sont les premiers éléments à retrouver
Le rapport officiel de LiteLLM, publié le 21 octobre et actualisé le soir même, désigne les sept paquets précompilés de la version 1.107.0. Ils ont été accessibles sur PyPI entre 13 h 39 et 15 h 23, heure française. Côté Docker, les étiquettes v1.107.0, latest, main-latest et main-stable ont également pointé vers des images compromises, avec une fin d’exposition indiquée à 16 h 20 pour Docker Hub.
Avec une étiquette mouvante, le diagnostic se complique. Retrouver « latest » dans un fichier de déploiement ne dit pas quelle image a réellement démarré. Il faut rapprocher l’historique du lancement et l’identifiant exact de l’image ; le projet publie les empreintes concernées dans son rapport.
Autre piège : le code visible sous le tag officiel GitHub n’incluait pas les fichiers malveillants. Un audit limité au dépôt source pouvait donc manquer les artefacts distribués. Dans ce cas, c’est bien le paquet installé ou l’image exécutée qui constitue la pièce déterminante.
Supprimer LiteLLM ne révoque pas les clés déjà dérobées
L’enquête publique sur GitHub décrit des fichiers capables de se lancer au démarrage de Python. Le risque ne se limite donc pas à un appel explicite à LiteLLM dans votre programme. Les chercheurs ont notamment recherché des clés de fournisseurs d’IA, des accès cloud et des informations de connexion présentes sur l’hôte.
Prenons une application munie d’une clé d’IA facturée à l’usage. Retirer le logiciel qui l’a dérobée ne retire pas la copie détenue ailleurs. Cette clé peut continuer à autoriser des requêtes jusqu’à sa révocation. Le même raisonnement vaut pour les autres identifiants auxquels l’environnement avait accès.
Le projet signale que les clients Enterprise utilisant son registre privé n’étaient pas concernés par cette distribution. Il faut vérifier le canal effectivement utilisé : l’inventaire doit porter sur les paquets et conteneurs réellement déployés.
Pourquoi lancer pip pour réparer peut aggraver la situation
La recommandation la plus inhabituelle est de ne pas commencer par exécuter pip dans l’environnement affecté. Pip fonctionne avec Python ; son lancement peut réactiver les mécanismes de démarrage piégés. LiteLLM recommande d’abord de neutraliser les fichiers malveillants et le processus détaché, puis de réinstaller une version explicitement identifiée comme antérieure à l’incident. Reconstruire l’environnement ou l’image depuis une base saine est préférable à une correction approximative sur place.
La remise en état comporte plusieurs tâches, qui ne se remplacent pas :
- Contenir l’exécution : identifier les hôtes et conteneurs concernés, puis suivre la procédure officielle de neutralisation.
- Remplacer l’environnement : repartir d’artefacts vérifiés plutôt que conserver une installation dont l’intégrité est douteuse.
- Révoquer et renouveler les secrets : clés API, identifiants cloud et autres accès que l’hôte pouvait atteindre.
- Examiner l’activité : chercher les utilisations inattendues des comptes et clés exposés, pas seulement les fichiers laissés sur le disque.
Le rapport précise que l’absence d’un fichier témoin ne suffit pas à innocenter une machine : un nettoyage temporaire ou un conteneur détruit peut effacer ces traces. À l’inverse, conserver les journaux et les empreintes des images aide à déterminer le périmètre réel. Le retrait de 1.107.0 des plateformes ferme la porte aux nouvelles installations ; il ne règle pas à lui seul les accès déjà volés.
Eric Thomas suit l’actualité de Windows, des logiciels, de la cybersécurité grand public et des outils web. Il s’intéresse aux mises à jour système, aux nouveautés informatiques et aux solutions pratiques qui améliorent l’expérience numérique au quotidien.
