Mistral AI, TeamPCP et les 450 dépôts fantômes : le démenti qui confirme le vrai risque
Intelligence artificielle

Mistral AI, TeamPCP et les 450 dépôts fantômes : le démenti qui confirme le vrai risque

Une revendication spectaculaire, un démenti calculé

L’affaire Mistral AI commence par une revendication typique de l’économie de l’extorsion cybercriminelle : un groupe baptisé TeamPCP affirme détenir environ 5 Go d’archives internes, près de 450 dépôts privés et des éléments liés à des projets clients ou métiers. Le prix demandé serait de 25 000 dollars, avec menace de publication gratuite en l’absence d’acheteur. Clubic rapporte cette revendication en la présentant comme non vérifiée, tout en soulignant que les noms d’archives affichés par les attaquants évoquent des briques sensibles : inférence, fine-tuning, outils internes, tableaux de bord, agents métiers et projets verticaux.

Numerama, qui a contacté Mistral AI, apporte la pièce la plus importante du dossier : l’entreprise française dément un piratage massif de son code source et affirme que les attaquants n’ont pas accédé à ses données clients, à ses services hébergés ni à ses environnements de recherche et de test. Mais ce démenti n’est pas un blanc-seing. Mistral reconnaît qu’un système de gestion de code a été temporairement compromis le 12 mai 2026 dans le contexte d’une attaque de chaîne d’approvisionnement liée à TanStack. Autrement dit, l’entreprise conteste l’ampleur de la prise, pas l’existence d’un incident.

C’est là que l’affaire devient intéressante. Dans une crise cyber, un démenti partiel est souvent une opération de bornage : il vise à tracer une ligne entre ce qui est confirmé, ce qui est plausible et ce qui relève encore de la mise en scène criminelle. Ici, Mistral dit en substance : oui, il y a eu compromission ; non, elle n’a pas touché le cœur stratégique que les pirates prétendent vendre.

Ce qui est confirmé : les SDK Mistral ont bien été touchés

La source la plus solide reste l’avis de sécurité officiel publié par Mistral. L’entreprise y indique avoir été affectée par une attaque de chaîne d’approvisionnement causée par la compromission de TanStack, un logiciel tiers. Selon cet avis, un appareil de développeur a été impliqué, mais l’enquête forensique de Mistral conclut que son infrastructure n’a pas été compromise.

Les versions touchées sont précisément listées : côté npm, les paquets @mistralai/mistralai en versions 2.2.2, 2.2.3 et 2.2.4, ainsi que les variantes Azure et GCP en versions 1.7.1, 1.7.2 et 1.7.3 ; côté PyPI, le paquet mistralai 2.4.6. La fenêtre d’exposition est courte mais réelle : les paquets npm compromis ont été mis en ligne le 11 mai à 22 h 45 UTC et retirés le 12 mai à 01 h 53 UTC ; la version PyPI compromise a été publiée le 12 mai à 00 h 05 UTC et retirée à 03 h 05 UTC.

Mistral nuance toutefois l’impact : les paquets npm compromis seraient inoffensifs, car leur script renvoyait vers un fichier inexistant. La version PyPI est plus préoccupante. L’avis indique qu’elle exécutait un script malveillant à l’import sur Linux, lançant un processus en arrière-plan destiné à récolter des identifiants dans des emplacements courants. Pour les développeurs ayant installé cette version, la recommandation est claire : nettoyer les systèmes concernés, vérifier les artefacts et caches, puis faire tourner les secrets exposés.

Le lien TanStack : quand la confiance devient le vecteur d’attaque

Le postmortem de TanStack permet de comprendre le mécanisme de fond. Le 11 mai 2026, un attaquant a publié 84 versions malveillantes dans 42 paquets @tanstack. L’attaque aurait combiné un abus du déclencheur pull_request_target de GitHub Actions, un empoisonnement de cache et l’extraction en mémoire d’un jeton OIDC depuis un runner GitHub Actions. TanStack insiste sur un point crucial : les jetons npm n’auraient pas été volés et le workflow de publication n’aurait pas été compromis au sens classique. C’est pire, d’une certaine façon : l’attaquant a utilisé la chaîne de publication légitime comme un cheval de Troie.

Socket, SecurityWeek et The Hacker News rattachent cet épisode à la campagne Mini Shai-Hulud, attribuée avec divers degrés de confiance à TeamPCP. Le mode opératoire vise les secrets des développeurs et des environnements CI/CD : jetons GitHub, clés cloud, identifiants npm, secrets Kubernetes, clés SSH, coffres de mots de passe et configurations d’outils d’IA. La finalité n’est pas seulement d’infecter un poste ; elle est de rebondir vers d’autres paquets, d’autres mainteneurs et d’autres infrastructures.

C’est exactement ce qui rend l’incident Mistral plus sérieux que ne le laisserait croire la seule expression « dépôts non critiques ». Dans une startup IA, la surface d’attaque ne se limite pas aux modèles. Elle comprend les SDK publics, les pipelines de build, les dépôts privés, les outils internes, les notebooks, les systèmes de support, les environnements de test, les secrets de déploiement et les intégrations clients. Même une compromission périphérique peut donner aux attaquants une carte partielle de l’organisation.

Pourquoi le chiffre de 450 dépôts doit rester au conditionnel

Le cœur de la revendication TeamPCP reste non vérifié publiquement. Ni Clubic ni Numerama ne valident l’authenticité complète des 5 Go annoncés. Les noms de fichiers affichés peuvent être authentiques, partiels, recyclés, embellis ou fabriqués pour maximiser la pression médiatique. Les forums cybercriminels fonctionnent comme des places de marché où la réputation du vendeur dépend de sa capacité à dramatiser l’actif volé.

Cela dit, la réponse de Mistral laisse ouverte une hypothèse intermédiaire : les attaquants ont pu accéder à certains dépôts secondaires ou non critiques, sans pour autant atteindre les modèles, les données clients ou les environnements de recherche. Dans une communication de crise, cette distinction est essentielle, mais elle ne neutralise pas totalement le risque. Un dépôt « non critique » peut contenir des conventions de nommage, des endpoints internes, des schémas d’architecture, des tests, des scripts d’automatisation, voire des références à des clients ou à des projets futurs.

Le prix réclamé, 25 000 dollars, est lui aussi révélateur. Pour une entreprise valorisée à plusieurs milliards, la somme paraît faible. Mais l’objectif d’une telle vente n’est pas nécessairement d’obtenir une rançon maximale auprès de la victime ; il peut être de monétiser rapidement des fragments de données, de nuire à la réputation ou de prouver la capacité du groupe à frapper une cible très visible.

Les startups IA, cibles idéales d’une extorsion moderne

Mistral AI est une cible symbolique : champion européen de l’IA, concurrent d’OpenAI, Google et Anthropic, acteur de souveraineté technologique. Cette visibilité crée un multiplicateur de risque. Un incident limité chez un fournisseur banal resterait peut-être confiné à une note de sécurité. Chez Mistral, il devient un récit mondial : le champion français a-t-il été percé ? Ses modèles sont-ils exposés ? Ses clients sont-ils concernés ?

Les startups IA cumulent plusieurs facteurs de vulnérabilité. Elles avancent vite, recrutent massivement, multiplient les expérimentations, utilisent des chaînes open source complexes et exposent des SDK que les développeurs installent dans des environnements riches en secrets. Elles sont aussi entourées d’un écosystème de partenaires, de clients pilotes et d’intégrations cloud qui élargissent la surface d’attaque.

Les normes et cadres existants disent déjà où regarder. Le NIST, avec le Secure Software Development Framework, insiste sur l’intégration de pratiques de sécurité dans tout le cycle de développement. La CISA présente le SBOM comme un outil de transparence pour comprendre les composants et dépendances logiciels. En Europe, le Cyber Resilience Act pousse vers une logique de sécurité tout au long du cycle de vie des produits numériques. L’incident Mistral illustre précisément cette bascule : la cybersécurité n’est plus un sujet d’infrastructure isolée, mais une propriété de la chaîne logicielle complète.

Ce que Mistral doit maintenant prouver

La bonne gestion de crise ne consiste pas seulement à dire « l’impact est limité ». Elle consiste à démontrer pourquoi il l’est. Mistral a déjà publié des versions touchées, des fenêtres d’exposition, des indicateurs de compromission et des étapes de remédiation. C’est un début solide. Mais l’enjeu des prochains jours sera la transparence incrémentale : quels dépôts ont été consultés ? Des secrets étaient-ils présents ? Des clients doivent-ils être notifiés ? Les journaux Git, CI/CD et cloud confirment-ils l’absence de mouvement latéral ?

La prospective est nette : les attaques contre les startups IA vont cibler de moins en moins les modèles eux-mêmes et de plus en plus les outils qui permettent de les construire, de les déployer et de les consommer. SDK, registres de paquets, GitHub Actions, environnements de développeurs et agents de code deviennent la nouvelle périphérie critique.

Dans cette affaire, TeamPCP cherche peut-être à vendre un trophée gonflé. Mais Mistral reconnaît assez d’éléments pour que l’incident serve d’avertissement. Le démenti partiel n’efface pas l’aveu : un maillon de la chaîne a cédé. Pour une entreprise d’IA à forte visibilité, c’est déjà un signal stratégique.

Sources d'actualité

Références complémentaires