Le 21 octobre, une version piégée de LiteLLM, un outil très utilisé par les développeurs pour accéder aux modèles d’IA, a été diffusée par ses canaux officiels. Le rapport d’incident de l’éditeur remonte jusqu’à une erreur de mai : une clé publiée par mégarde, effacée, mais jamais désactivée. Pour une PME, la leçon dépasse le monde du logiciel : un secret exposé se change, il ne se cache pas.
Ce qui s’est passé
LiteLLM est une « passerelle » open source : elle permet aux applications de dialoguer avec différents modèles d’IA par une seule porte d’entrée. Le 21 octobre, sa version 1.107.0, publiée sur les dépôts officiels de paquets Python et d’images Docker, contenait un programme qui volait les identifiants des machines où elle était installée (notre bulletin du 22 octobre). Elle a été retirée dans les heures qui ont suivi.
Le 23 octobre, l’éditeur a publié son rapport d’incident, repris par The Hacker News (The Hacker News, 24 octobre 2026). Il raconte une chaîne d’erreurs ordinaires, que l’attaquant a mises bout à bout.
Comment l’attaque a fonctionné
Une clé publiée par erreur, jamais désactivée. Le 27 mai, un fichier de configuration est publié dans un dépôt de code public. Il contient la clé maîtresse d’une plateforme interne qui pilote des agents d’IA. L’équipe le voit vite, efface le fichier et note la clé comme « à révoquer ». La révocation n’est jamais faite. La clé reste valable plus de quatre mois.
Un accès bien trop large. Le 10 octobre, l’attaquant utilise la clé. Dans la plateforme, il trouve un jeton GitHub (une sorte de badge numérique) prévu pour que les agents d’IA proposent des modifications de code. Ce badge n’était pas limité : il appartenait au compte propriétaire de l’organisation et ouvrait tous les dépôts de l’éditeur.
Des traces effacées au fur et à mesure. Avec ce badge, l’attaquant lance des tâches automatiques dans des branches de code créées puis supprimées en quelques minutes. Elles lui envoient les badges de deux développeurs et d’autres secrets. Presque rien ne reste visible dans l’historique.
Une règle assouplie la même semaine. Normalement, publier une version demandait la validation d’un compte spécial lié à un appareil physique, au bureau. Pour publier plus vite, l’éditeur avait autorisé, cette semaine-là, n’importe quels deux développeurs à lancer et valider une publication. Le 21 octobre, l’attaquant fait exactement cela avec les deux badges volés.
Une alerte venue de l’extérieur. Un chercheur d’une société de sécurité signale la version piégée moins d’une demi-heure après sa publication. Selon Microsoft, cité par The Hacker News, désinstaller l’outil ne suffit pas toujours : des fichiers malveillants peuvent rester en place.
Ce qu’on ne sait pas encore
- Le nombre d’installations touchées : non communiqué.
- L’identité de l’attaquant : inconnue selon l’éditeur.
- Ce qui a été fait des identifiants volés chez les utilisateurs de la version piégée.
Ce que ça change pour une PME
- Un mot de passe ou une clé exposé se change, tout de suite. L’effacer d’un document, d’un courriel ou d’un dépôt ne le rend pas inutilisable. La fiche « Pourquoi et comment bien gérer ses mots de passe ? » de Cybermalveillance.gouv.fr rappelle les bons réflexes ; ils valent aussi pour les clés d’accès.
- Limitez les accès donnés aux outils, y compris aux outils d’IA et d’automatisation : un compte dédié, avec les seuls droits nécessaires, jamais celui du dirigeant ou de l’administrateur principal.
- Donnez une date de fin à chaque exception. Une règle de sécurité assouplie « juste pour cette semaine » doit avoir un responsable et une échéance.
- Demandez à votre prestataire de développement s’il sait, en quelques heures, si un composant piégé annoncé publiquement est présent dans vos applications.
Le regard de l’auditeur
Quatre questions à vous poser, ou à poser à votre prestataire. Elles s’inspirent de ce que vérifie un auditeur ISO 27001 :
- Quand un mot de passe ou une clé a été exposé chez nous, qui vérifie qu’il a vraiment été changé, et pas seulement effacé ?
- Quels accès avons-nous donnés à nos outils d’automatisation ou d’IA, et au nom de quel compte ?
- Quelles exceptions à nos règles de sécurité sont en cours, qui les a décidées et quand prennent-elles fin ?
- Si un logiciel que nous utilisons était piégé, combien de temps nous faudrait-il pour savoir sur quelles machines il est installé ?
Pour les pros : notre analyse technique (mode opératoire, MITRE ATT&CK, questions d’audit ISO 27001).
Dossiers : Fournisseurs et sous-traitants · Mots de passe et accès volés
Cet article prolonge notre bulletin de veille du 25 octobre 2026.
Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.