La prochaine version majeure de npm, la v12, dont la sortie est prévue en juillet 2026, ne lancera plus par défaut les scripts d'installation des dépendances.
Nous sommes soulagés de l'apprendre. La désactivation des scripts d'installation est la modification la plus utile que npm puisse apporter à ses paramètres par défaut. La communauté a subi une avalanche attaques de la chaîne d’approvisionnement l'année dernière, telles que Nx s1ngularity et Shai-Hulud, qui exploitaient les scripts post-installation. Cette mise à jour de npm est un changement tant attendu qui réduira considérablement un vecteur d'attaque majeur de la chaîne d'approvisionnement.
Ce qui change avec npm
Lorsque vous exécutez npm install Aujourd'hui, n'importe quel paquet de votre arborescence de dépendances peut définir des scripts de cycle de vie appelés preinstall, installer, ou post-installation, et npm les exécute automatiquement pour vous. Le code s'exécute dès l'installation, avant même que vous n'importiez quoi que ce soit ou que vous n'exécutiez votre propre code.
La version 12 met fin à cela. Les scripts ne s'exécutent que pour les paquets que vous avez ajoutés à une liste blanche, que vous créez à l'aide de la commande `npm approve-scripts` ; vous bloquez les autres à l'aide de la commande `npm deny-scripts`, puis vous les intégrez au reste de votre projet.
D'autres modifications mineures sont également incluses. Les dépendances Git ne sont plus résolues à moins que vous ne passiez --autoriser-git, ce qui met fin à une voie d'exécution plus discrète dans laquelle le fichier npmrc d'une dépendance Git pouvait remplacer l'exécutable Git et exécuter du code même avec --ignore-scripts définir. Les dépendances d'URL distantes, comme les archives tar, cessent également d'être résolues, à moins que vous ne passiez --autoriser-à-distance, ce qui empêche un attaquant de pointer une dépendance vers une URL externe qu'il contrôle et de remplacer la charge utile à tout moment.
La liste blanche couvre également le code qui n'apparaît jamais dans le champ « scripts ». Lorsqu'un paquet fournit un fichier binding.gyp, npm exécute implicitement une reconstruction node-gyp pour celui-ci lors de l'installation ; ainsi, une dépendance dont le fichier package.json est irréprochable peut tout de même exécuter du code simplement en contenant ce fichier de construction. La version 12 traite cette construction comme un script déclaré ; elle sera donc bloquée à moins que le paquet ne figure sur votre liste blanche. Notre équipe de recherche a récemment mis en évidence à quel point cette voie d'attaque potentielle est étrange et dangereuse.
Tout cela est déjà disponible dans la version 11.16.0 de npm, sous forme d'avertissements, ce qui vous permet de voir ce qui ne fonctionne plus avant de procéder à la mise à jour.
Les failles d'exploitation post-installation corrigées par la mise à jour npm
Presque tous les vers et les programmes de vol d'identifiants qui ont touché npm depuis l'automne dernier s'exécutaient lors de l'installation plutôt qu'au moment de l'exécution. Le schéma habituel est le suivant : un pirate prend d'abord le contrôle d'un paquet de confiance, généralement en piratant le compte npm d'un responsable ou en volant un jeton de publication. Il publie ensuite une nouvelle version dans laquelle un script post-installation a été ajouté au fichier package.json, tout en laissant souvent le code source d'origine intact, de sorte que rien ne semble anormal à première vue.
Lorsque quelqu'un exécute la commande « npm install », npm lance automatiquement ce script en tant qu'utilisateur. Il identifie la machine, télécharge la charge utile réelle depuis le serveur d'un pirate, l'exécute, puis s'efface, tandis que la charge utile recherche des jetons, des clés SSH et d'autres informations sensibles, avant de les transmettre
Dans le cadre de ces attaques, il n'est même pas nécessaire d'utiliser le paquet malveillant ni même de l'importer pour en être victime. Il suffit d'avoir la malchance d'exécuter npm install tant que le paquet est infecté.
Avec les paramètres par défaut de la version 12, l'installation s'arrêterait tout simplement au niveau du paquet malveillant, à moins que ce paquet précis ne figure sur la liste blanche que vous avez validée. L'attaquant peut toujours publier la version corrompue, mais sur une machine équipée de la version 12, celle-ci restera inerte dans le répertoire node_modules.
Pourquoi est-ce important ?
La vague d'attaques par scripts post-installation a commencé à l'automne dernier, et elle ne s'est pas vraiment calmée depuis. Nous avons constaté une telle attaque sur un paquet Red Hat il y a tout juste une semaine. Parmi les attaques majeures qui ont exploité cette faille et ont tenu nos chercheurs en sécurité éveillés la nuit, on peut citer :
- Nx Singularity, août 2025. Un jeton de publication volé a permis de diffuser des versions malveillantes de Nx dont le script post-installation, telemetry.js, s'exécutait lors de l'installation. Ce script récupérait les jetons GitHub, les identifiants npm, les clés SSH et les portefeuilles cryptographiques, puis les téléchargeait vers des dépôts GitHub publics. Les quelque 2 300 identifiants ainsi récoltés ont servi de base à de futures attaques.
- Shai-Hulud, novembre 2025. Un ver autoreproducteur qui a touché près de 500 paquets sur Zapier, ENS, PostHog, Postman et AsyncAPI a installé le runtime Bun lors de la configuration, a exécuté TruffleHog pour récupérer des secrets, puis les a publiés dans des dépôts GitHub publics.
- Le piratage d'Axios, mars 2026. Un compte de responsable de maintenance piraté a intégré une dépendance dont le seul but était d'exécuter un hook post-installation et d'implanter un RAT multiplateforme. Axios enregistre environ 100 millions de téléchargements par semaine.
- Mini Shai-Hulud, mai 2026. Un ver dérivé du Shai-Hulud original, qui implanta un hameçon préinstallé permettant d’extraire l’environnement d’exécution Bun et d’exécuter un programme de vol d’identifiants. Il s’est propagé à travers plus d’une centaine de paquets sur TanStack, UiPath et Mistral AI, devenant ainsi le premier ver npm à publier un logiciel malveillant doté d’une provenance de compilation valide.
Il ne s'agit pas uniquement d'un problème lié à npm, même si ce dernier est la principale cible. Le même principe se retrouve dans d'autres écosystèmes, comme Composer pour PHP, où plus de 200 versions de Laravel-Lang ont été réécrites en mai afin d'exécuter automatiquement un programme de vol d'identifiants via l'autoloader (Composer dispose désormais d'un filtrage natif des logiciels malveillants, optimisé par Aikido, pour protéger les utilisateurs en aval).
Que faire maintenant ?
Passez à la version 11.16.0 ou ultérieure de npm, car ces trois modifications y sont déjà intégrées, accompagnées d'avertissements. Si vous utilisez déjà la version 11.15.0 ou une version ultérieure, --autoriser-git est désormais disponible, et --autoriser-à-distance depuis la version 11.15.0, vous pouvez donc commencer à les verrouiller sans attendre la version 12. Pour les scripts, exécutez npm approve-scripts --allow-scripts-pending pour voir ce qui serait bloqué, approuver les paquets auxquels vous faites confiance, puis valider la mise à jour package.json. Tout ce que vous ignorez cessera de fonctionner dès la sortie de la version 12. Vérifiez bien cela, car de nombreux paquets légitimes utilisent des scripts d'installation pour la compilation et la configuration natives, et une fois que la valeur par défaut aura changé, ces installations devront être approuvées.
Vous pouvez également installer Safe Chain Aikido, un wrapper sécurisé gratuit pour npm, npx et yarn qui s'intègre à votre flux de travail actuel et vérifie la présence de logiciels malveillants dans chaque paquet avant son installation. Il vous empêche d'installer accidentellement des logiciels malveillants et impose un délai d'attente pour les nouvelles versions des paquets, ce qui empêche un grand nombre de paquets compromis d'atteindre votre appareil.
De bons paramètres par défaut protègent ceux qui ne consultent jamais le journal des modifications (c'est-à-dire presque tout le monde, la plupart du temps, à l'exception des chercheurs en sécurité et des personnes dotées d'un sens de la prudence bien placé). Le fait que npm rende cette option sécurisée par défaut est une bonne décision. Cela n'aurait pas dû prendre une année de chaos public pour que cela se produise, et cela ne résoudra pas tous les problèmes, mais nous sommes ravis que cette mesure soit enfin en place.
