Le 23 octobre 2026, LiteLLM a publié la chaîne d’attaque qui a mené à la diffusion, le 21 octobre, d’une version piégée de sa passerelle d’accès aux modèles d’IA sur PyPI et Docker. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : mode opératoire, correspondance avec MITRE ATT&CK, détection, questions d’audit ISO 27001 et pistes de sensibilisation. Elle repose sur la synthèse de The Hacker News, qui cite le rapport de l’éditeur et les analyses de Socket et de Microsoft ; le nombre d’environnements touchés et l’usage fait des identifiants volés ne sont pas documentés.
Pour une lecture orientée dirigeant, voir notre décryptage « Une clé oubliée pendant quatre mois : comment une version piégée de LiteLLM a été publiée ».
Contexte
- Source : rapport d’incident de LiteLLM du 23 octobre 2026, complété par les analyses de Socket (tâches CI malveillantes) et de Microsoft (charge utile), le tout repris par The Hacker News, 24 octobre 2026.
- Cible directe : l’organisation GitHub de l’éditeur de LiteLLM, passerelle open source distribuée sur PyPI, Docker Hub et GHCR.
- Victimes indirectes : environnements ayant installé la version 1.107.0 ou tiré les images publiées le 21 octobre, entre 11 h 40 et environ 14 h 20 UTC. Nombre non communiqué.
- Attaquant : inconnu selon l’éditeur.
- Durée d’exposition du secret initial : 136 jours entre la publication de la clé (27 mai) et sa première utilisation connue (10 octobre).
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Exposition du secret | 27 mai : clé maîtresse d’une plateforme interne d’orchestration d’agents publiée dans un fichier de configuration d’un dépôt public ; commit écrasé, révocation prévue mais non faite | T1593.003 Search Open Websites/Domains: Code Repositories ; T1552.001 Credentials In Files |
| Accès initial | 10 octobre : connexion à la plateforme avec la clé | T1078 Valid Accounts |
| Vol de jeton | Extraction d’un jeton OAuth GitHub CLI configuré pour que les agents ouvrent des demandes de modification ; non restreint et rattaché au compte propriétaire de l’organisation | T1528 Steal Application Access Token |
| Collecte de secrets | 10 et 12 octobre : commits dans des branches éphémères créées depuis un commit légitime, avec un message anodin, déclenchant une tâche CI qui exfiltre les jetons de deux mainteneurs, des clés d’API de fournisseurs d’IA, la clé de l’outil de détection de secrets, un état de session de navigateur de tests et des identifiants de bases de données ; branches supprimées en quelques minutes | T1552 Unsecured Credentials ; T1567 Exfiltration Over Web Service ; T1070 Indicator Removal (l’exécution via une tâche CI n’a pas de correspondance simple dans notre lecture) |
| Levée des contrôles | 21 octobre, 10 h 08-11 h 08 UTC : contournement de la protection de branche, source de la chaîne de publication redirigée vers un dépôt imitant celui de l’éditeur | T1562 Impair Defenses |
| Publication piégée | 11 h 39-11 h 46 UTC : déclenchement avec un jeton volé, approbation avec le second, publication sur PyPI puis Docker Hub et GHCR. La règle habituelle (approbation par un compte lié à un appareil physique) avait été assouplie la même semaine | T1195.002 Compromise Software Supply Chain |
| Charge utile | Fichiers exécutés à chaque démarrage de Python, même sans import de LiteLLM ; vol d’identifiants (SSH, Git, variables d’environnement, registres de paquets, cloud, navigateurs) ; porte dérobée Unix qui récupère du code toutes les heures | T1546 Event Triggered Execution (crochets de démarrage Python) ; T1555 Credentials from Password Stores ; T1041 Exfiltration Over C2 Channel ; T1105 Ingress Tool Transfer |
| Effacement | 11 h 53-11 h 54 UTC : suppression des enregistrements d’exécution de production et de préproduction | T1070 Indicator Removal |
| Usage des identifiants volés | Non documenté dans les sources consultées | Non déterminable |
Faits techniques connus
Le jeton GitHub volé donnait un accès de niveau propriétaire à tous les dépôts de l’organisation : l’attaquant aurait pu supprimer lui-même la règle de publication, ce qu’il n’a pas fait, sans doute pour rester discret selon l’éditeur. Selon Socket, la collecte du 12 octobre visait aussi la clé de l’outil de détection de secrets de l’organisation, ce qui pouvait donner à l’attaquant une visibilité sur les alertes susceptibles de le trahir, et un état de session de navigateur permettant un accès authentifié sans mot de passe ni second facteur. Selon Microsoft, les fichiers de démarrage malveillants sont placés hors du dossier de l’application : désinstaller LiteLLM peut les laisser actifs.
Ce qu’on ne sait pas
- Le nombre d’installations de la version piégée.
- Ce que l’attaquant a fait des secrets collectés chez l’éditeur et chez les utilisateurs.
- La manière dont la clé exposée a été trouvée par l’attaquant.
Détection : ce qui reste observable
La détection est venue de l’extérieur : un chercheur d’Upwind a signalé la version piégée à 12 h 06 UTC, 26 minutes après sa publication sur PyPI, et le registre l’a mise en quarantaine à 13 h 23 UTC. Entre le 10 et le 21 octobre, l’attaquant a agi avec des secrets légitimes et effacé ses traces au fil de l’eau. Signaux accessibles dans ce type de cas :
- utilisation d’une clé ou d’un jeton qui aurait dû être révoqué, ou depuis une origine inhabituelle ;
- dans le journal d’audit de l’organisation : branches créées puis supprimées en quelques minutes, exécutions de tâches supprimées, ajout ou modification d’un fichier de tâche CI ;
- modification d’une protection de branche ou de la source de la chaîne de publication ;
- publication d’une version dont l’étiquette dans le dépôt source ne correspond pas au paquet publié (l’éditeur précise que l’étiquette officielle de la version 1.107.0 ne contient pas les fichiers malveillants) ;
- côté utilisateurs : fichiers de démarrage Python inattendus dans les environnements, connexions sortantes périodiques depuis des machines de développement ou de production.
Point clé de réponse à incident côté utilisateurs : retirer la version 1.107.0 ne suffit pas. Il faut vérifier et nettoyer les fichiers de démarrage Python, puis changer tous les secrets accessibles depuis les environnements touchés.
Questions d’audit ISO 27001:2022
- A.5.17 et A.5.26 (informations d’authentification, réponse aux incidents de sécurité de l’information) : « Montrez-moi votre procédure en cas d’exposition d’un secret (clé d’API, jeton, mot de passe). Prévoit-elle la révocation et le remplacement, et pas seulement la suppression du fichier ou du commit ? Montrez-moi la preuve de révocation pour le dernier secret exposé. »
- A.5.15, A.5.18 et A.8.2 (contrôle d’accès, droits d’accès, droits d’accès privilégiés) : « Quels jetons et comptes techniques sont configurés dans vos outils d’automatisation et d’agents d’IA ? À quel compte sont-ils rattachés, quelle est leur portée, et quand ont-ils été revus pour la dernière fois ? »
- A.8.32, A.8.4 et A.8.25 (gestion des changements, accès au code source, cycle de vie de développement sécurisé) : « Qui peut déclencher et approuver une publication ? Montrez-moi la dernière dérogation à cette règle : qui l’a décidée, après quelle appréciation du risque, avec quelle date de fin ? Les modifications des protections de branche et de la chaîne de publication déclenchent-elles une alerte ? »
- A.5.19, A.5.21, A.8.15 et A.8.16 (fournisseurs, chaîne d’approvisionnement des TIC, journalisation, surveillance) : « Vos applications figent-elles les versions et les empreintes des composants open source ? En combien de temps savez-vous si une version compromise annoncée publiquement est présente chez vous ? Les journaux d’audit de votre forge de code sont-ils conservés hors de la forge ? »
Pistes de sensibilisation
- Pour les développeurs et les équipes data : atelier « Effacer n’est pas révoquer ». Reprendre la chronologie, puis s’exercer sur un faux secret publié dans un dépôt de test : qui prévenir, comment révoquer, comment vérifier que l’ancienne clé ne fonctionne plus. Support : la fiche « Pourquoi et comment bien gérer ses mots de passe ? » de Cybermalveillance.gouv.fr, dont les principes valent pour les clés d’API.
- Pour les dirigeants : « L’exception temporaire ». Montrer qu’une règle assouplie pour une semaine a suffi à l’attaquant, puis lister les exceptions en cours, chacune avec un responsable et une date de fin. Support : « Les 10 mesures essentielles pour assurer votre sécurité numérique » de Cybermalveillance.gouv.fr.
À lire aussi : notre décryptage « Une clé oubliée pendant quatre mois : comment une version piégée de LiteLLM a été publiée » et 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.