● Journal du Net 📅 13/05/2026 à 18:13

Cybersécurité 👤 Benjamin Polge

🏷️ Tags : supply chain attack chine vulnérabilités cert docker gemini kubernetes pm rag rte stoc

Les SDK de Mistral AI ont été compromis pendant plusieurs heures dans une attaque de supply chain d'ampleur. Retour sur l'événement et les conséquences à en tirer. C'est la quatrième vague d'attaques du genre en moins de huit mois. Le 12 mai 2026, une nouvelle attaque sur la supply chain logicielle a touché plus de 170 packages, dont 168 sur npm et 2 sur PyPI. Parmi eux, les SDK de Mistral AI ont été compromis pendant un peu plus de trois heures. Une fenêtre suffisante pour que certains utilisateurs aient pu installer ou mettre à jour le SDK avec la version vérolée. A l'intérieur, un malware de type stealer, conçu pour aspirer les identifiants de la machine infectée et se propager à d'autres packages, doublé d'un mécanisme de sabotage déclenché en cas de révocation des tokens. Retour sur l'incident, les mesures de remédiation et les bonnes pratiques pour limiter le risque à l'avenir. Un dépôt contaminé et c’est toute la chaîne open source qui s’enflamme A l'origine de l'attaque, tout part du dépôt de TanStack (une bibliothèque JavaScript pour React). Le 10 mai, un pirate du groupe TeamPCP crée un fork du repository TanStack/router. En exploitant une chaîne de trois vulnérabilités dans GitHub Actions, il parvient à faire publier 84 versions vérolées sur 42 packages @tanstack/*, sous l'identité légitime de TanStack et avec une certificat de provenance SLSA valide. Aucun token npm n'a été volé, le workflow de publication officiel n'a pas été modifié. C'est le premier cas documenté de package npm malveillant avec un SLSA valide. Le payload est conçu pour se propager. Une fois exécuté, il cherche les tokens GitHub Actions et npm accessibles depuis la machine. C'est par ce mécanisme que l’appareil d’un développeur de Mistral, contaminé via les packages TanStack, a servi de tremplin pour publier les SDK vérolés. UiPath (65 packages), OpenSearch et Guardrails AI ont été touchés par le même effet domino, pour un total de plus de 170 packages compromis. Or, tous les systèmes ayant installé les packages Mistral concernés (voir ci-après) entre 00:45 et 03:53 (heure de Paris) le 12 mai ont récupéré le malware sur leur machine. Mistral précise dans son advisory la liste des packages touchés, à savoir : Pour npm : @mistralai/mistralai en version 2.2.2, 2.2.3, 2.2.4 @mistralai/mistralai-azure en version 1.7.1, 1.7.2, 1.7.3 @mistralai/mistralai-gcp en version 1.7.1, 1.7.2, 1.7.3 Pour PyPi : mistralai en version 2.4.6 L'éditeur français ajoute toutefois que, bien que les packages npm aient été corrompus, le malware n'aurait pas pu s'exécuter par manque d'un fichier essentiel à son fonctionnement. En revanche, le malware injecté dans le package PyPI, lui, était bien opérationnel. Que pouvait faire concrètement le malware ? Selon l’analyse de Wiz, le malware visait avant tout à voler des identifiants et à se propager. Une fois exécuté, il cherchait des tokens GitHub, npm, GitLab ou CircleCI, des identifiants cloud AWS, GCP et Azure, des secrets Kubernetes, Vault ou encore des accès à des registres de packages. Ces identifiants pouvaient ensuite être exfiltrés vers plusieurs canaux de commande et de contrôle, puis réutilisés pour publier à leur tour de nouvelles versions vérolées de packages auxquels la victime avait accès. Un véritable vers en somme. Certaines variantes installaient aussi un processus persistant sur macOS ou Linux capable de surveiller la révocation de tokens GitHub et de déclencher une commande destructive sur la machine (rm -rf ~/). Le malware intégrait aussi un mécanisme d’évitement géographique, s’il détectait une configuration système en langue russe, il s’arrêtait sans exfiltrer les données. Comment savoir si vous avez été infecté ? Quelle procédure de remédiation ? La première étape est de vérifier vos fichiers de dépendances (générés automatiquement par npm ou pip qui listent précisément les versions de chaque bibliothèque installée) dans votre projet. Cherchez les versions listées ci-dessus. Mistral précise que vous n'êtes pas concerné si ces versions ne figurent ni dans ces fichiers, ni dans vos caches de build, ni dans vos artefacts de déploiement, ni dans vos miroirs de packages privés. Sur un système Linux ou macOS potentiellement touché, il faut également rechercher la présence du fichier /tmp/transformers.pyz (indicateur d'une exécution réussie du payload PyPI) et d'un processus persistant nommé gh-token-monitor, installé respectivement sous ~/.config/systemd/user/ sur Linux ou ~/Library/LaunchAgents/ sur macOS. Si vous avez identifié une version compromise dans votre environnement, la première action à mener est de supprimer le processus gh-token-monitor avant toute autre chose, avant de révoquer vos tokens GitHub. Une fois cette petite bombe désamorcée, vous pouvez procéder à la révocation de tous vos tokens accessibles depuis la ou les machines touchées (tokens npm et GitHub, AWS, GCP, Azure, Kubernetes, SSH…). Mistral recommande également de bloquer au niveau du DNS ou du proxy les domaines git-tanstack[.]com et *.getsession.org, ainsi que l'adresse IP 83.142.209.194, utilisés par le malware. Comment limiter les risques à l’avenir ? Première mesure de bon sens : ne pas appliquer automatiquement les dernières mises à jour de vos dépendances. Introduire un délai volontaire de 24 heures avant toute mise à jour laisse le temps à la communauté, et aux outils de détection automatisée, de signaler une version vérolée. Dans le même esprit, tenir à jour une liste précise des dépendances de chacun de vos projets n'est pas optionnel. Cela vous permettra, lors du prochain incident, de savoir en quelques minutes si vous êtes exposé plutôt qu'en quelques heures. Côté droit d’accès, la leçon est brutale : un développeur dont la machine est compromise ne devrait jamais pouvoir, seul, publier l'intégralité du SDK d'un éditeur. Appliquez le principe du moindre privilège, chaque compte, pipeline ou prestataire ne dispose que des droits strictement nécessaires à sa tâche, et ne stockez pas l'ensemble de vos credentials sur une seule et même machine. Des recommandations que le CERT-FR formalisait déjà en 2019 dans son guide sur les attaques visant la supply chain. Le cas des agents IA de code C'est probablement là que se situe le vrai danger. Les assistants de code type Claude Code, Codex, Gemini CLI & co installent des dépendances en quelques secondes, souvent sans validation humaine. Si l'agent tourne dans un environnement qui contient vos tokens GitHub, vos credentials cloud et vos accès SSH (autrement dit, votre machine de développement), le risque est maximal. Premier conseil, faites tourner vos agents dans des environnements isolés (containers Docker, sandbox, voire VPS dédié) qui ne contiennent que les credentials strictement nécessaires à la tâche en cours. Deuxième réflexe, désactivez l'auto-approbation des commandes d'installation et imposez une validation manuelle pour vos projets stratégiques. Enfin dernier conseil : donner uniquement les droits nécessaires à votre agent de code, ni plus ni moins. Les attaques sur la supply chain logicielle ne sont pas nouvelles. Ce qui change en 2026, c'est l'échelle. L'interconnexion croissante des composants open source, combinée à la vitesse de génération et d'installation de dépendances permise par les agents de code, transforme chaque package compromis en bombe à fragmentation. Là où un développeur prenait quelques minutes à évaluer une nouvelle bibliothèque, un agent en installe désormais une dizaine en quelques secondes.

🔗 Lire l'article original 👁️ 0 lecture