Shai-Hulud 2.0 : un ver a infecté des centaines de paquets npm
Fin novembre, un logiciel malveillant s'est propagé dans des centaines de bibliothèques JavaScript. Pourquoi ça concerne aussi les PME qui font développer leurs outils.
Entre le 21 et le 24 novembre 2025, une nouvelle vague d'attaque baptisée « Shai-Hulud 2.0 » a frappé npm, le registre où les développeurs JavaScript du monde entier téléchargent des bibliothèques toutes faites. Des centaines de paquets légitimes ont été piégés, des dizaines de milliers de dépôts de code ont vu des secrets publiés en clair. Vous n'avez peut-être jamais entendu parler de npm. Pourtant, si votre site, votre extranet ou votre application ont été développés en JavaScript, ils en dépendent très probablement. Ce qui s'est passé, et les bonnes questions à poser à ceux qui maintiennent vos logiciels.
Ce qui s'est passé
Un logiciel moderne n'est jamais écrit de zéro. Il assemble des centaines de briques open source : une pour lire les dates, une pour envoyer des e-mails, une pour dessiner des graphiques. Ces briques, appelées dépendances, s'installent automatiquement depuis npm.
Les attaquants ont pris le contrôle de comptes de mainteneurs de paquets, puis publié des versions piégées de bibliothèques connues. Parmi les éditeurs touchés cités par la presse spécialisée : Zapier, PostHog, Postman, AsyncAPI, ENS Domains. Selon les décomptes des éditeurs de sécurité, entre six cents et huit cents paquets ont été compromis.
Le mécanisme est celui d'un ver. Dès qu'un développeur ou un serveur d'intégration installe un paquet piégé, le code malveillant s'exécute, cherche les identifiants présents sur la machine (accès GitHub, clés AWS, Google Cloud, Azure, secrets de déploiement) et les publie dans de nouveaux dépôts GitHub publics. Il se sert ensuite des accès volés pour piéger d'autres paquets. La société Wiz a compté plus de 25 000 dépôts exposant des secrets en quelques jours.
Ce qui rend cette vague plus dangereuse
Une première version de Shai-Hulud avait déjà frappé en septembre. La nouvelle diffère sur deux points.
- Elle s'exécute avant même l'installation. Le code passe par l'étape de « préinstallation » du paquet. Il suffit donc de lancer l'installation des dépendances pour être touché, sur le poste d'un développeur comme sur les serveurs qui construisent et déploient automatiquement les logiciels.
- Elle peut détruire. Selon l'analyse de Check Point, si le ver ne parvient pas à voler d'identifiants, il peut chercher à effacer des données de la machine.
Ce que ça change pour une PME
Le risque principal n'est pas que votre site affiche soudain une page piratée. C'est que les accès de vos prestataires, ou de votre équipe interne, soient volés : accès à votre hébergement, à votre base de données, à votre dépôt de code. Avec ces clés, un attaquant n'a pas besoin de forcer la porte.
Concrètement, une PME est exposée si :
- son logiciel a été construit ou mis à jour entre fin novembre et début décembre, avec des dépendances installées sans version figée ;
- les secrets de production (mots de passe de base de données, clés d'API) traînent sur les postes des développeurs ou dans les outils d'intégration continue ;
- personne ne sait dire quelles dépendances sont utilisées, ni dans quelle version.
Les questions à poser à votre prestataire
Vous n'avez pas besoin de comprendre le détail technique pour vérifier que le sujet est traité. Posez ces questions, par écrit :
- Nos logiciels utilisent-ils un des paquets compromis ? Des listes publiques existent ; la vérification prend quelques minutes sur un projet bien tenu.
- Les versions des dépendances sont-elles figées ? Un fichier de verrouillage (« lockfile ») garantit qu'on installe exactement ce qui a été testé, et pas la dernière version publiée la veille.
- Les secrets ont-ils été changés ? Après une alerte de ce type, les éditeurs recommandent de faire tourner tous les identifiants qui ont pu être exposés : jetons GitHub, clés cloud, accès de déploiement.
- Où sont stockés nos secrets de production ? La bonne réponse : dans un coffre dédié ou dans la configuration du serveur, jamais dans le code ni sur un ordinateur portable.
- Qui reçoit les alertes de sécurité sur nos dépendances ? Si la réponse est « personne », c'est le vrai problème.
Comment nous travaillons
Sur les logiciels que nous développons et maintenons, les dépendances sont verrouillées, les secrets de production ne sont jamais dans le code, et les alertes de sécurité font partie de la maintenance : quand une alerte comme celle-ci tombe, nous vérifions chaque projet et nous prévenons le client de ce que nous avons trouvé et fait. Le code source vous est remis, documenté, pour que n'importe quel développeur puisse refaire ces vérifications.
Si vous faites développer un logiciel métier ou une application, demandez comment ces sujets sont traités avant de signer, pas après une alerte. Et si vous avez un doute sur un logiciel existant, nous pouvons en parler lors d'un rendez-vous de 30 minutes.