Aller au contenu

Mini Shai-Hulud : un ver infecte des paquets de TanStack, Mistral AI et UiPath

Le 11 mai, une nouvelle vague d'attaques a publié des versions piégées de bibliothèques connues sur npm et PyPI, dont le SDK de Mistral AI. Ce qui change par rapport à mars.

Le 11 mai 2026, des versions piégées de plusieurs bibliothèques connues ont été publiées sur npm, le magasin de paquets JavaScript, et sur PyPI, son équivalent pour Python. Parmi les projets touchés : TanStack, très utilisé pour construire des applications web, OpenSearch, UiPath, et le kit de développement officiel de Mistral AI. La campagne, baptisée « Mini Shai-Hulud », avait connu une première vague le 29 avril. Six semaines après l'attaque d'axios, elle montre une évolution inquiétante : le code malveillant ne se contente plus de voler, il cherche à se propager.

Ce qui s'est passé

D'après l'alerte publiée le 12 mai par le service de cybersécurité du NHS anglais, la campagne a publié des centaines de versions malveillantes de paquets légitimes, en deux phases, le 29 avril et le 11 mai. L'alerte cite notamment les paquets npm de routage de TanStack, le SDK JavaScript de Mistral AI, le client OpenSearch et un paquet d'UiPath, ainsi que des versions Python de la bibliothèque de Mistral et de guardrails-ai.

Le code malveillant, fortement masqué, s'exécute à l'installation ou au chargement du paquet. Il récupère les jetons d'accès à GitHub et à npm, les secrets des chaînes de déploiement automatique, les identifiants cloud et les clés d'API présents sur la machine. Surtout, selon le NHS, si l'environnement infecté a le droit de publier des paquets ou d'accéder à d'autres dépôts, le malware peut s'injecter dans d'autres projets. C'est ce comportement de ver qui lui vaut son nom, en référence à une campagne de 2025.

Côté OpenSearch, l'avis publié par le projet indique que les versions piégées étaient des versions de développement non publiées officiellement, en ligne pendant environ deux heures et demie le soir du 11 mai avant d'être retirées. Les versions stables publiées auparavant n'étaient pas compromises.

Ce qui change par rapport à axios

Fin mars, l'attaque d'axios reposait sur un seul compte de mainteneur détourné, et visait à installer un logiciel d'accès à distance (nous la racontions dans notre article sur axios). Mini Shai-Hulud franchit une étape : chaque machine infectée qui détient des droits de publication devient un nouveau point de départ. Un développeur qui travaille sur plusieurs projets, ou un serveur de compilation qui publie des paquets, peut, sans le savoir, contaminer d'autres bibliothèques, et donc d'autres entreprises.

Autre détail révélateur : l'alerte du NHS recommande d'examiner les dossiers de configuration des éditeurs de code et des assistants de programmation IA dans les répertoires des développeurs. Les outils de développement eux-mêmes sont devenus une cible.

Ce que ça change pour une PME

Vous n'êtes probablement pas un éditeur de bibliothèques open source. Mais si votre entreprise fait développer des logiciels, en interne ou par un prestataire, la question est la même qu'en mars : les machines qui fabriquent vos logiciels détiennent-elles des secrets qui ouvrent vos systèmes ? Le ver cherche précisément ces secrets : clés d'hébergement, accès aux dépôts de code, clés d'API de vos services. Une intégration de l'IA de Mistral dans un de vos outils, par exemple, pouvait installer la version piégée si elle a été mise à jour pendant la fenêtre.

Ce que nous conseillons

  1. Demandez à votre prestataire s'il utilise l'un des paquets cités, et si une installation a eu lieu le 29 avril ou le 11 mai.
  2. En cas de doute, considérez la machine comme compromise : réinstallation et changement de tous les secrets accessibles, comme le recommandent le NHS et OpenSearch.
  3. Imposez un délai avant d'adopter une nouvelle version : la plupart des versions piégées sont retirées en quelques heures. Attendre quelques jours avant de mettre à jour coûte peu et protège beaucoup.
  4. Verrouillez les versions des dépendances dans chaque projet.
  5. Limitez les droits des machines de compilation : une machine qui compile n'a pas besoin de pouvoir publier partout, ni d'accéder à la production.
  6. Surveillez les publications : une publication de paquet ou une modification de dépôt que personne n'a faite doit déclencher une alerte.

Ce qu'on en retient

Trois attaques majeures en deux mois sur la chaîne d'approvisionnement logicielle, axios, Mini Shai-Hulud et ses deux vagues : ce n'est plus un risque théorique, c'est l'environnement normal du développement en 2026. Il ne s'agit pas de renoncer à l'open source, sans lequel aucun logiciel moderne n'existerait, mais de traiter les dépendances comme des fournisseurs : on sait lesquels on utilise, on contrôle quand on change de version, et on limite ce à quoi ils ont accès.

Sur nos projets de logiciel, les versions sont verrouillées, les mises à jour se font de manière volontaire et différée, et les secrets de production ne vivent pas sur nos postes. Le code source vous est remis : la liste des dépendances est vérifiable par n'importe qui. Si vous voulez faire le point sur la façon dont vos logiciels sont fabriqués, parlons-en lors d'un rendez-vous de 30 minutes.

À relire sur le même sujet : Shai-Hulud 2.0 : un ver a infecté des centaines de paquets npm.

Sources

Vos logiciels sont-ils fabriqués en sécurité ?

On regarde avec vous leurs dépendances, leurs secrets et leur chaîne de déploiement.

À lire ensuite

Tous les articles →