Mistral AI : nouvelle fuite ou ancien code remis en vente?

Le 16 septembre 2026, un compte présent sur un forum cybercriminel a affirmé vendre le code source complet de Mistral AI. L’entreprise dit n’avoir trouvé aucune preuve confirmant une nouvelle compromission. Plusieurs indices rapprochent cette offre de l’incident de mai, sans permettre de trancher entre une revente et une nouvelle intrusion.

L’incident de mai est documenté

En mai 2026, Mistral AI a été touchée par une attaque de chaîne logicielle liée à la compromission de TanStack, un composant tiers. Un ver automatisé a conduit à la publication de versions contaminées de certains SDK npm et PyPI.

Dans son avis de sécurité MAI-2026-002, Mistral indique qu’un appareil de développement compromis a participé à l’incident, sans impact identifié sur son infrastructure globale. Les versions malveillantes ont été publiées pendant quelques heures les 11 et 12 mai.

Le paquet Python était le plus préoccupant. La version 2.4.6 pouvait exécuter un script à l’import sur les systèmes Linux, lancer un processus en arrière-plan et rechercher des identifiants dans des emplacements courants. Le paquet npm compromis ne pouvait pas exécuter correctement son code malveillant, car le fichier référencé par setup.mjs n’existait pas.

Mistral a aussi indiqué qu’un système de gestion du code avait été temporairement compromis. L’entreprise a affirmé que les services hébergés, les données gérées pour ses clients ainsi que les environnements de recherche et de test n’avaient pas été touchés. Un dépôt interne compromis ne signifie donc pas automatiquement que les modèles, les données clients ou les services en production ont été exfiltrés.

La publication de septembre reprend des éléments de mai

Le nouveau vendeur demande un paiement en cryptomonnaie et affirme disposer de l’intégralité du code source de Mistral AI. Son annonce intervient quelques mois après une première revendication portant sur près de 450 dépôts et environ 5 Go de données, proposée pour 25 000 dollars.

Le compte utilisé en septembre a été créé le même mois. Il compte peu de publications et affiche une réputation limitée, tout en arborant un niveau de profil particulièrement élevé. Cette incohérence peut correspondre à une escroquerie, à un alias récent ou à un intermédiaire agissant pour un autre groupe. Elle ne permet pas, à elle seule, de conclure.

Le vendeur a diffusé un arbre de 339 fichiers. Au moins quatre noms apparaissent également dans les éléments associés à la revendication de mai : mistral-inference-privatemistral-inference-internalmistral-finetune-internal et mistral-common-internal.

Ce chevauchement rend plausible l’hypothèse d’une revente du même ensemble de fichiers. Il ne prouve toutefois ni que l’archive est authentique, ni qu’elle provient exactement de la première fuite. Des noms de dépôts peuvent être copiés, réutilisés ou présentés sans que leur contenu corresponde à celui annoncé.

La date des fichiers permettrait de distinguer les deux scénarios

Le volume annoncé et la présence de noms de dépôts internes ne suffisent pas. Pour étayer l’hypothèse d’une nouvelle intrusion, il faudrait trouver des commits, des fichiers ou des secrets créés après le 12 mai, date de référence de l’incident initial.

La présence d’identifiants encore valides après les opérations de nettoyage constituerait aussi un indice important. Elle montrerait que l’archive contient des éléments auxquels les attaquants auraient eu accès plus tard, ou que certains secrets n’avaient pas été révoqués lors de la seconde compromission supposée.

À l’inverse, une archive composée uniquement de fichiers antérieurs à mai conforterait l’idée d’une remise en circulation de données déjà volées. Cela resterait un problème de confidentialité et de sécurité pour Mistral, mais pas la preuve d’un nouvel accès aux systèmes.

Acheter ou télécharger une archive proposée sur un forum clandestin n’est pas une méthode fiable de vérification. Le fichier peut être incomplet, falsifié, contaminé ou utilisé pour voler les données de l’acheteur. La revendication doit être évaluée à partir d’éléments vérifiables et de l’enquête de l’entreprise, pas à partir de la promesse commerciale du vendeur.

Les vérifications utiles pour les utilisateurs des SDK

Les développeurs et les entreprises qui ont utilisé les paquets concernés doivent vérifier plusieurs emplacements, même si la version compromise n’est plus installée directement :

• les environnements ayant installé la version Python 2.4.6 pendant la période d’exposition;
• les fichiers de dépendances et les fichiers de verrouillage npm ou Python;
• les caches de paquets, les miroirs privés, les images de conteneurs et les artefacts de compilation;
• les hôtes Linux ayant importé le paquet Python concerné;
• les identifiants qui auraient pu être accessibles depuis ces environnements.

Si une version affectée est retrouvée, la suppression du paquet ne suffit pas. Il faut examiner les indicateurs de compromission publiés dans l’avis de sécurité de Mistral, isoler les machines concernées si nécessaire et renouveler les secrets exposés. Les clés d’API, les jetons de dépôt et les identifiants présents dans un environnement compromis doivent être considérés comme potentiellement récupérables.

La compromission de mai est établie, mais la vente de septembre ne démontre pas encore une seconde attaque. La chronologie des fichiers et la validité des secrets restent les éléments les plus utiles pour distinguer la revente de données déjà volées d’un nouvel accès aux systèmes.