La prochaine version majeure de npm, la v12, prévue pour juillet 2026, cessera d'exécuter les scripts d'installation des dépendances par défaut.
Nous sommes soulagés de l'apprendre. Désactiver les scripts d'installation est le changement le plus utile que npm puisse apporter à ses paramètres par défaut. La communauté a subi un déluge d'attaques de la chaîne d’approvisionnement au cours de la dernière année, telles que Nx s1ngularity et Shai-Hulud, qui exploitaient les scripts postinstall. Cette mise à jour de npm est un changement attendu depuis longtemps qui réduira considérablement un vecteur d'attaques de la chaîne d’approvisionnement majeur.
Ce que npm est en train de changer
Lorsque vous exécutez npm install aujourd'hui, n'importe quel package, n'importe où dans votre arbre de dépendances, peut définir des scripts de cycle de vie appelés preinstall, install, ou post-installation, et npm les exécute automatiquement pour vous. Le code s'exécute dès l'installation, avant que vous n'importiez quoi que ce soit ou n'exécutiez votre propre code.
La v12 met fin à cela. Les scripts ne s'exécutent que pour les packages que vous avez placés sur une liste d'autorisation, que vous construisez avec npm approve-scripts, bloquez le reste avec npm deny-scripts, et commitez avec le reste de votre projet.
D'autres changements mineurs l'accompagnent. Les dépendances Git ne sont plus résolues à moins que vous ne passiez --allow-git, ce qui ferme une voie d'exécution plus discrète où le fichier npmrc d'une dépendance Git pourrait outrepasser l'exécutable Git et exécuter du code même avec --ignore-scripts défini. Les dépendances d'URL distantes, comme les tarballs HTTPS, cessent également d'être résolues à moins que vous ne passiez --allow-remote, fermant ainsi une voie où un attaquant pourrait faire pointer une dépendance vers une URL externe qu'il contrôle et échanger la charge utile à tout moment.
La liste d'autorisation couvre également le code qui n'apparaît jamais dans le champ scripts. Lorsqu'un package contient un fichier binding.gyp, npm exécute une reconstruction node-gyp implicite pour celui-ci lors de l'installation, ainsi, une dépendance avec un package.json impeccable peut toujours exécuter du code simplement en contenant ce fichier de build. La v12 traite cette compilation comme un script déclaré, elle sera donc bloquée à moins que le package ne figure sur votre liste d'autorisation. Notre équipe de recherche a récemment détaillé à quel point cette voie d'attaque potentielle est étrange et dangereuse.
Tout cela est déjà présent dans npm 11.16.0, derrière des avertissements, afin que vous puissiez voir ce qui ne fonctionne plus avant de mettre à niveau.
Les exploits postinstall que la modification de npm corrige
Presque tous les vers et voleurs de credentials qui ont frappé npm depuis l'automne dernier se sont exécutés au moment de l'installation plutôt qu'à l'exécution. Le schéma de ces attaques implique généralement qu'un attaquant prenne d'abord le contrôle d'un package de confiance, généralement en phishing un compte npm de mainteneur ou en volant un jeton de publication. Ensuite, les attaquants publient une nouvelle version avec un script postinstall ajouté à son package.json, laissant souvent la source réelle intacte, de sorte que rien ne semble manifestement anormal.
Lorsque quelqu'un exécute npm install, npm exécute ce script automatiquement en tant qu'utilisateur. Il prend l'empreinte numérique de la machine, télécharge la charge utile réelle depuis un serveur d'attaquant, l'exécute et se supprime, tandis que la charge utile recherche des jetons, des clés SSH et d'autres éléments sensibles, puis les exfiltre.
Dans ces attaques, il n'est même pas nécessaire d'utiliser le package malveillant ou de l'importer pour en devenir victime. Il suffit d'avoir la malchance d'exécuter npm install pendant que le package est infecté.
Avec la configuration par défaut de la v12, l'installation s'arrêterait simplement au package malveillant, à moins que ce package exact ne figure sur la liste blanche que vous avez validée. L'attaquant peut toujours publier la version empoisonnée, mais sur une machine avec la v12, elle reste là comme des fichiers inertes dans node_modules.
Pourquoi c'est important
La vague d'attaques par scripts post-installation a commencé l'automne dernier et elles n'ont pas vraiment cessé. Nous avons vu cette attaque sur un package Red Hat il y a tout juste une semaine. Parmi les attaques majeures qui en ont tiré parti et ont tenu nos chercheurs en sécurité en alerte, on compte :
- Nx s1ngularity, août 2025. Un jeton de publication volé a poussé des versions malveillantes de Nx dont le script post-installation, telemetry.js, s'est exécuté à l'installation. Il a récupéré des jetons GitHub, des identifiants npm, des clés SSH et des portefeuilles de cryptomonnaies, puis les a téléchargés sur des dépôts GitHub publics. Les quelque 2 300 identifiants qu'il a collectés ont alimenté de futures attaques.
- Shai-Hulud, novembre 2025. Un ver auto-réplicatif qui a touché près de 500 packages chez Zapier, ENS, PostHog, Postman et AsyncAPI, a installé le runtime Bun pendant la configuration, a exécuté TruffleHog pour récupérer des secrets et les a déversés dans des dépôts GitHub publics.
- Le détournement d'axios, mars 2026. Un compte de mainteneur piraté a livré une dépendance qui n'existait que pour exécuter un hook post-installation et déposer un RAT multiplateforme. axios enregistre environ 100 millions de téléchargements par semaine.
- Mini Shai-Hulud, mai 2026. Un ver dérivé de l'original Shai Hulud, qui a implanté un hook de pré-installation téléchargeant le runtime Bun et exécutant un voleur d'identifiants. Il s'est propagé à travers plus d'une centaine de packages chez TanStack, UiPath et Mistral AI et est devenu le premier ver npm à publier des malwares avec une provenance de build valide.
Ce n'est pas seulement un problème npm, bien que npm soit la cible principale. La même idée apparaît dans d'autres écosystèmes, comme Composer de PHP, où plus de 200 versions de Laravel-Lang ont été réécrites en mai pour exécuter automatiquement un voleur d'identifiants via l'autoloader (Composer dispose désormais d'un filtrage natif des malwares propulsé par Aikido pour protéger les utilisateurs en aval).
Que faire maintenant
Mettez à niveau vers npm 11.16.0 ou une version ultérieure, car les trois changements y sont déjà présents, masqués par des avertissements. Si vous êtes déjà sur la version 11.15.0 ou supérieure, --allow-git est disponible dès maintenant, et --allow-remote depuis la version 11.15.0, vous pouvez donc commencer à les sécuriser sans attendre la v12. Pour les scripts, exécutez npm approve-scripts --allow-scripts-pending pour voir ce qui serait bloqué, approuvez les packages auxquels vous faites confiance et validez le fichier mis à jour package.json. Tout ce que vous ignorez cessera de s'exécuter lorsque la v12 sera déployée. Vérifiez cela, car de nombreux packages légitimes utilisent des scripts d'installation pour les builds natives et la configuration, et une fois le comportement par défaut modifié, ces installations nécessiteront une approbation.
Vous pouvez également installer Safe Chain par Aikido, un wrapper sécurisé gratuit pour npm, npx et yarn qui s'intègre à votre flux de travail actuel et vérifie chaque package à la recherche de malwares avant l'installation. Il vous empêche d'installer accidentellement des malwares et impose une période d'attente pour les nouvelles versions de packages, ce qui empêche un bon nombre de packages compromis d'atteindre votre appareil.
De bonnes configurations par défaut protègent les personnes qui n'ouvrent jamais un changelog (c'est-à-dire presque tout le monde, presque tout le temps, à l'exception des chercheurs en sécurité et des personnes suffisamment paranoïaques). Que npm rende cela sûr par défaut est la bonne décision. Cela n'aurait pas dû prendre une année de dégâts publics pour se produire, et cela ne résoudra pas tout, mais nous sommes heureux que ce soit là.
