Dans cet article
Si votre entreprise utilise une application d'IA, un chatbot ou un outil interne connecté à des modèles comme GPT, Claude ou Gemini, posez aujourd'hui une seule question à votre équipe technique : un serveur, un poste ou une chaîne de build a-t-il installé LiteLLM en version 1.107.0 le 21 octobre 2026 ? Cette version a été publiée par des attaquants et est restée sur PyPI environ deux heures, de 11 h 39 à 13 h 23 UTC, avec près de 49 000 téléchargements. Elle vole les clés cloud, les clés des fournisseurs d'IA, les mots de passe de bases de données et les clés SSH. Si la réponse est oui, la désinstaller ne suffit pas : reconstruisez la machine à partir d'une image saine et changez toutes les clés auxquelles elle avait accès. La version sûre est la 1.106.2.
Que s'est-il passé exactement ?
LiteLLM est une bibliothèque et une passerelle open source qui permet à une même application de dialoguer avec des dizaines de modèles d'IA via une interface unique ; c'est pourquoi de nombreuses entreprises la placent au cœur de leurs produits d'IA. Selon Chainguard, elle a dépassé 100 millions de téléchargements sur PyPI au cours du dernier mois, et plus de 2 000 autres paquets en dépendent : beaucoup d'équipes l'installent sans le savoir.
D'après le rapport d'incident officiel de LiteLLM, les attaquants ont récupéré des jetons d'accès GitHub qui avaient fuité dans les journaux du projet. Le 21 octobre à 10 h 08 UTC, ils ont utilisé un identifiant de développeur privilégié pour contourner la protection de branche et modifier le processus de publication afin qu'il compile depuis un dépôt au nom trompeur, «Berri-AI/litellm» au lieu de «BerriAI/litellm». À 11 h 39 UTC, les fichiers malveillants arrivaient sur PyPI, et à 11 h 46 UTC des images Docker piégées sortaient sous les tags v1.107.0, latest, main-latest et main-stable. PyPI a retiré la version avant 13 h 23 UTC, et les tags Docker ont été nettoyés à 14 h 20 UTC.
C'est la deuxième attaque contre ce projet cette année. Chainguard rappelle qu'en mars 2026, un groupe avait utilisé un jeton PyPI volé pour publier les versions 1.82.7 et 1.82.8.
Que vole la version malveillante ?
Le plus dangereux, c'est qu'elle n'attend pas que votre application utilise LiteLLM. La version ajoutait des fichiers de démarrage Python qui s'exécutent à chaque lancement de Python sur la machine, même pour une commande sans rapport. Selon l'analyse de Wiz, le voleur collectait :
- Les clés cloud AWS, Google Cloud et Azure, depuis les fichiers de configuration, les variables d'environnement et les métadonnées des serveurs.
- Les clés API d'OpenAI, d'Anthropic, de Cohere et d'autres fournisseurs d'IA, c'est-à-dire votre facture et vos données.
- Les clés SSH privées, l'historique du shell, ainsi que les mots de passe et cookies enregistrés dans les navigateurs.
- Jusqu'à 500 identifiants de fournisseurs stockés dans la base de données de LiteLLM Proxy.
Les attaquants n'ont pas attendu. Wiz a observé des identifiants AWS volés testés environ 4,5 heures après leur vol, depuis des serveurs de build et des nœuds Kubernetes. Le logiciel installait aussi un second étage qui télécharge du code à distance toutes les heures : la machine reste ouverte même après la suppression du paquet.
Mon entreprise est-elle concernée ?
Vous n'êtes probablement pas concerné si votre équipe fixe les versions exactes et n'a rien mis à jour entre 11 h 39 et 14 h 20 UTC le 21 octobre. Vous pouvez l'être si l'un des cas suivants s'applique :
- Un serveur ou un conteneur exécute «pip install litellm» sans version fixe, ou récupère le tag Docker «latest».
- Une chaîne CI/CD a reconstruit ce jour-là pendant cette fenêtre.
- Un développeur a testé LiteLLM sur son poste ce jour-là.
- Votre système utilise un autre paquet qui dépend de LiteLLM.
LiteLLM indique que les clients de sa version Enterprise privée n'ont pas été touchés.
Cinq mesures à prendre aujourd'hui
- Chercher : la version 1.107.0 dans les fichiers de verrouillage, les journaux de build et les images de conteneurs, ainsi que les fichiers cook.pth et sitecustomize.py dans le dossier des paquets Python.
- Reconstruire : si vous la trouvez, ne vous contentez pas de désinstaller. Le rapport officiel prévient que lancer pip dans un environnement infecté peut réactiver le logiciel malveillant. Reconstruisez la machine ou le conteneur à partir d'une image saine.
- Changer toutes les clés : clés et rôles cloud, clés des fournisseurs d'IA, mots de passe de bases de données et clés SSH accessibles depuis la machine. Partez du principe qu'elles sont déjà entre les mains des attaquants.
- Examiner les journaux : vérifiez l'activité cloud depuis le 21 octobre à la recherche d'appels inhabituels comme GetCallerIdentity, et surveillez la facture de votre fournisseur d'IA pour repérer des dépenses inconnues.
- Fixer les versions : installez litellm==1.106.2 ou un correctif officiel ultérieur, et figez chaque bibliothèque avec un fichier de verrouillage au lieu de récupérer «latest» automatiquement.
Si vous avez lu notre article sur les clés oubliées dans le code des agents IA, la leçon est la même sous un autre angle : les clés d'IA comptent désormais parmi les secrets les plus précieux de votre entreprise, et l'endroit où elles sont réunies devient une cible.
Le regard d'Origami
Personne n'a piraté le code de LiteLLM lui-même : les attaquants ont modifié sa façon d'être compilé et publié, si bien qu'une simple revue du code source n'aurait rien détecté. Protéger un produit d'IA ne se joue donc pas tant dans le choix de la bibliothèque que dans la manière de l'exploiter : versions figées, une clé distincte par environnement avec le strict minimum de droits, des plafonds de dépenses chez chaque fournisseur et une trace claire de qui accède à quoi. Lorsque nous construisons des systèmes d'IA pour des entreprises chez Origami, nous traitons la passerelle vers les modèles comme la partie la plus sensible du système, car elle détient les clés de tout. Si vous souhaitez faire vérifier votre application d'IA au regard de cet incident, ou réorganiser ses clés et ses droits, contactez-nous.
Sources
Questions fréquentes
Comment savoir si mon entreprise a installé la version piratée de LiteLLM ?
Demandez à votre équipe de chercher litellm 1.107.0 dans les fichiers de verrouillage, les journaux de build et les images de conteneurs, ainsi que cook.pth ou sitecustomize.py dans le dossier des paquets Python. La fenêtre de risque était le 21 octobre 2026, de 11 h 39 à 14 h 20 UTC.
Suffit-il de désinstaller le paquet ?
Non. Le logiciel malveillant s'exécute à chaque lancement de Python et installe un second étage qui télécharge du code toutes les heures. Reconstruisez la machine ou le conteneur à partir d'une image saine, puis changez toutes les clés accessibles.
Quelle version de LiteLLM est sûre ?
LiteLLM recommande de fixer la version 1.106.2 ou antérieure. Selon le rapport d'incident officiel, les clients de sa version Enterprise privée n'ont pas été touchés.
Nous n'utilisons pas LiteLLM directement. Pouvons-nous être concernés ?
Oui. Plus de 2 000 paquets dépendent de LiteLLM, il a donc pu être installé comme dépendance d'une autre bibliothèque. Vérifiez la liste complète de vos dépendances, pas seulement ce que votre équipe a installé elle-même.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
