Pourquoi des paquets liés à TanStack, Mistral AI et UiPath se retrouvent-ils au cœur d’une vaste cyberattaque ?

Plus de 170 paquets open source ont été touchés en mai 2026, avec une mécanique simple et redoutable, publier des versions piégées sur npm et PyPI, et laisser les installations automatisées faire le reste. Dans une fenêtre d’environ cinq heures, au moins 401 artefacts malveillants ont été mis en ligne, visant des projets très utilisés, dont des paquets TanStack téléchargés à grande échelle chaque semaine.

3 éditeurs touchés, 2 registres visés, TanStack, Mistral AI, UiPath, l’attaque Mini Shai-Hulud surprend npm et PyPI

Ce qui frappe, c’est le caractère coordonné, on ne parle pas d’un module obscur, mais d’un ensemble de bibliothèques présentes dans des chaînes CI/CD réelles. Des noms comme TanStack, Mistral AI ou UiPath se retrouvent au centre d’un scénario typique de supply chain, l’attaquant n’a pas besoin d’entrer dans votre serveur, il lui suffit d’entrer dans vos dépendances.

SafeDep décrit 401 versions malveillantes publiées en cinq heures

L’attaque, baptisée Mini Shai-Hulud, se distingue par son rythme. Le 11 mai, plus de 170 packages ont été frappés, et au moins 401 artefacts ont été publiés sur une période d’environ cinq heures. Pour un développeur, c’est le pire timing, une publication rapide, puis une disparition avant que les alertes humaines ne s’allument, pendant que les pipelines installent “la dernière version” sans poser de questions.

Dans les faits, la campagne a ciblé plusieurs écosystèmes et plusieurs familles de paquets. On retrouve des modules JavaScript et Python, donc des usages front, back, scripts internes, automatisation et data. C’est ce mélange qui rend l’incident difficile à circonscrire, une entreprise peut n’utiliser qu’un seul des paquets touchés et se retrouver malgré tout exposée, juste parce qu’il est dans un build quotidien.

Le tableau de chasse inclut des espaces de noms très identifiables, @tanstack, @uipath, mais aussi des paquets liés à OpenSearch et à d’autres modules populaires. Le point clé, c’est l’effet de levier, un paquet maintenu sérieusement peut devenir un vecteur si une version malveillante se glisse dans le flux de distribution. Et quand les téléchargements se comptent en millions par semaine pour certains modules, la surface d’impact grimpe vite.

Tu peux voir la logique, frapper large, frapper vite, et profiter de l’automatisation. Beaucoup d’équipes ont des tâches planifiées qui exécutent des mises à jour ou reconstruisent des images, parfois plusieurs fois par jour. Dans ce contexte, une version compromise “vivante” quelques heures suffit. Ça met aussi une pression sur la détection, les outils doivent être capables d’identifier un comportement anormal à l’installation, pas seulement de vérifier un hash après coup.

TanStack: 42 paquets touchés, Router utilisé dans React, Vue et Solid

Le cas TanStack est particulièrement parlant, parce que la marque est associée à un outillage web très répandu. La campagne a touché 42 paquets TanStack, dont des composants liés au routeur, aux devtools et à des adaptateurs. Dans un parc applicatif moderne, ça veut dire des dépendances présentes dans des apps client, des back offices, des outils internes, et parfois des bibliothèques partagées entre équipes.

Le paquet TanStack Router est explicitement cité comme utilisé dans des applications basées sur React, Vue et Solid. Concrètement, si une équipe a une application React reconstruite à chaque merge, et qu’un job CI récupère une version compromise, le code malveillant peut se retrouver dans l’environnement de build. Même si l’attaque vise d’abord les postes et les secrets, le simple fait d’entrer dans un pipeline ouvre des portes.

Ce type d’attaque vise souvent ce qui traîne sur les machines de dev et dans les runners CI, tokens, clés d’API, identifiants cloud, variables de secrets. Le risque, c’est la chaîne, un vol de credentials peut mener à d’autres compromissions, puis à une propagation. C’est là que le côté “worm” mentionné dans les analyses prend tout son sens, un paquet compromis n’est pas juste un incident isolé, il peut devenir un multiplicateur.

Nuance importante, beaucoup vont chercher un coupable unique, “un mainteneur négligent”. Là, le signal renvoie plutôt à une campagne coordonnée, qui cible plusieurs projets à la fois. Ça change la posture, au lieu de se dire “on n’est pas TanStack, on s’en fiche”, il faut se dire “si notre chaîne dépend de l’écosystème npm, on est concernés”. Et ça vaut aussi pour les dépendances transverses, celles que personne ne regarde parce qu’elles “marchent”.

Mistral AI confirme une compromission via SDK, Azure et GCP

Mistral AI a confirmé avoir été impacté, avec des versions piégées publiées sur trois canaux de distribution, le SDK principal, l’intégration Azure et l’intégration GCP. Trois versions malveillantes ont été publiées pour chacun de ces canaux. Le point à retenir, c’est la précision, l’attaquant ne vise pas seulement “un paquet Python”, il vise des points d’entrée qui collent aux usages réels des entreprises.

La société indique qu’un appareil de développeur a été touché, et qu’il n’y a pas d’élément montrant une compromission de son infrastructure. Dit autrement, l’attaque ressemble à un scénario où la contamination passe par la chaîne de dépendances et les environnements de dev, pas par une intrusion directe dans les serveurs de l’éditeur. Pour les équipes qui consomment ces SDK, ça renforce l’idée que la frontière de sécurité ne se limite plus au SI central.

Des analyses techniques ont aussi mis en avant un serveur de commande et contrôle avec une adresse codée en dur, 83.142.209[.]194, et un mécanisme de repli nommé FIRESCALE si le serveur principal devient injoignable. Ce détail compte, parce qu’il montre une approche résiliente, même si un indicateur est bloqué, le code tente de continuer. Pour une équipe SOC, ça veut dire qu’un simple blocage DNS ne suffit pas toujours.

Le contexte s’alourdit avec les annonces du groupe attribué à la campagne, TeamPCP, qui a évoqué un “contest” autour de la compromission de paquets, avec une récompense de 1 000 dollars en Monero, et une menace de fuite d’environ 5 Go de code interne lié à Mistral AI, avec une demande de 25 000 dollars en “buy it now”. Même si ces annonces se jouent sur le terrain de l’extorsion, elles servent aussi de carburant à l’industrialisation de la méthode.

UiPath: 65 paquets npm compromis, la communauté demande un remède

Sur le volet UiPath, la campagne a touché 65 paquets côté npm, avec la publication de versions malveillantes sur l’ensemble de la plateforme d’automatisation. Là, l’impact potentiel dépasse le cercle des développeurs web, parce que l’automatisation est souvent branchée sur des systèmes métiers, des orchestrateurs, des environnements d’exécution, et parfois des accès à des applications internes sensibles.

Sur le forum communautaire, des utilisateurs ont rapidement demandé un “remedy”, ce qui reflète une réalité terrain, les entreprises veulent une procédure claire, quoi vérifier, quoi désinstaller, quoi régénérer. Ce n’est pas un débat théorique, quand ton équipe RPA dépend d’un stack de paquets, tu as besoin d’un plan d’action. Et dans ce genre d’incident, l’absence d’instructions simples peut conduire à des réactions incohérentes, ou à un faux sentiment de sécurité.

Le conseil opérationnel qui revient dans les recommandations de sécurité, c’est de vérifier si une version compromise a atteint l’environnement, de nettoyer, puis de faire une rotation de tous les secrets potentiellement exposés. Dit comme ça, c’est simple, dans la vraie vie, c’est lourd. Rotation de tokens, clés d’API, identifiants de registres, secrets CI, parfois clés cloud, ça demande un inventaire solide, et beaucoup d’équipes n’ont pas cet inventaire à jour.

Il y a aussi une dimension CI/CD souvent sous-estimée, l’audit des configurations GitHub Actions OIDC et des workflows pull_request_target, avec un risque de poisoning via cache. Si tu utilises des actions partagées, des caches de dépendances, et des déclencheurs sur PR, tu peux avoir un chemin d’attaque latéral. Critique au passage, trop d’équipes traitent encore la CI comme un “outil”, pas comme un actif critique, alors que c’est souvent l’endroit où résident les secrets les plus précieux.

pnpm et uv ajoutent un “cooling-off” de 24 h pour bloquer les versions trop récentes

Un enseignement concret ressort des retours d’analystes et d’ingénieurs sécurité, la fenêtre courte de publication est un avantage pour l’attaquant. D’où l’idée d’un délai de refroidissement, un “cooling-off period” qui empêche de résoudre des versions publiées trop récemment. Sur ce point, pnpm 11 active par défaut un paramètre minimumReleaseAge de 1440 minutes, soit 24 heures, et l’outil uv propose aussi ce type de mécanisme.

Le bénéfice est immédiat, si une version malveillante est en ligne quelques heures, elle ne sera pas installée automatiquement par un parc configuré avec ce seuil. Exemple concret partagé dans la communauté, une commande d’upgrade peut signaler qu’une version plus récente existe, mais refuser de la résoudre parce qu’elle est trop fraîche. Ce n’est pas une solution magique, mais ça transforme une attaque éclair en attaque qui doit durer plus longtemps, donc plus visible.

De plus, les recommandations de sécurité insistent sur la défense en profondeur, vérification de provenance, mais aussi analyse comportementale au moment de l’installation. L’idée, c’est de détecter des scripts d’installation anormaux, des accès réseau inattendus, ou des modifications suspectes dans l’environnement. Là encore, c’est facile à dire, mais ça demande des outils et une maturité. Beaucoup d’équipes n’ont pas d’observabilité sur ce qui se passe pendant un “npm install”.

Ce dossier rappelle une comparaison utile avec d’autres incidents supply chain, quand un plugin, une action CI ou un paquet populaire se fait contaminer, l’onde de choc vient du fait que tout est interconnecté. La leçon n’est pas “ne plus utiliser l’open source”, ce serait irréaliste. La leçon, c’est de traiter les dépendances comme une partie du périmètre de sécurité, avec des politiques de mise à jour, des garde-fous sur les versions, et des procédures de réponse à incident prêtes à déclencher, même quand l’attaque ne dure que quelques heures.

https://www.europe-infos.fr/actualites/9087/comment-choisir-un-vetement-professionnel-adapte-pour-prevenir-les-accidents-sur-le-lieu-de-travail/

https://www.europe-infos.fr/english/9081/french-students-pedal-9-miles-to-learn-local-history-turning-a-bike-ride-into-a-living-classroom/