Un ver qui se réplique tout seul, des milliers de secrets publiés au grand jour, des portefeuilles crypto siphonnés. npm v12 tire les leçons de l'hécatombe : plus aucun script d'installation ne s'exécutera sans votre accord.
Dans l'écosystème JavaScript, installer une bibliothèque revient depuis toujours à lui confier les clés de la machine : la commande npm install exécute automatiquement les scripts fournis par chaque paquet, sans rien demander à personne (et sans sandbox pour limiter ce que ce code peut faire sur votre système). GitHub, propriétaire du gestionnaire depuis 2020, a annoncé le 9 juin dans son journal des modifications la fin de ce régime. La version 12 de npm, attendue dans le courant de l'été, inversera la logique par défaut.
Trois verrous d'un coup pour npm v12
Le changement principal vise les scripts dits de cycle de vie, ces commandes preinstall et postinstall que les paquets déclenchent au moment de leur installation. npm v12 ne les exécutera plus, sauf approbation explicite du développeur, paquet par paquet. Le blocage couvre aussi les compilations de modules natifs et les scripts des dépendances locales ou Git. Deux protections viennent compléter le dispositif : les dépendances pointant vers des dépôts Git et celles téléchargées depuis des adresses distantes ne seront plus résolues par défaut.
Ce choix d'automatisation avait pourtant sa logique, et npm le défendait publiquement dès 2016 quand des chercheurs alertaient déjà sur le risque d'un ver : automatiser la compilation simplifiait la vie de millions de développeurs, et l'entreprise estimait le risque maîtrisable par une surveillance du registre. Dix ans et quelques catastrophes plus tard, la convenance a perdu l'arbitrage. La transition est d'ailleurs engagée : la version 11.16.0, déjà disponible, affiche des avertissements sur les paquets concernés, et une commande dédiée permet de constituer sa liste de confiance avant la bascule. GitHub cite nommément trois attaques que ces réglages auraient bloquées (la compromission d'eslint-config-prettier, celle des paquets de Toptal et le ver Shai-Hulud), une liste qui commence discrètement en 2025 et préfère ne pas remonter plus loin dans l'historique.
Huit ans d'attaques pour en arriver là
La longue série d'incidents qui a finalement convaincu GitHub commence en novembre 2018, quand le paquet event-stream embarquait un voleur de cryptomonnaies via un simple script d'installation. Ont suivi ua-parser-js en octobre 2021, le sabotage volontaire des paquets colors et faker en janvier 2022, puis eslint-config-prettier à l'été 2025. Le saut qualitatif date de septembre 2025 : Shai-Hulud, premier ver auto-répliquant observé dans l'écosystème, a compromis plusieurs centaines de paquets en volant les jetons des mainteneurs pour se republier tout seul. Sa deuxième vague, fin novembre, a créé environ 25 000 dépôts GitHub remplis de secrets dérobés, et Trust Wallet lui a attribué 8,5 millions de dollars de cryptomonnaies envolées. Une réplique a encore frappé le 19 mai dernier : 639 versions piégées sur 323 paquets, publiées en moins d'une heure depuis un seul compte de mainteneur compromis.
npm était pourtant le dernier grand gestionnaire à maintenir ce comportement. Son concurrent pnpm bloque les scripts par défaut depuis janvier 2025 (une décision prise précisément en réaction à une vague d'attaques similaires), et Bun impose de son côté une liste de confiance explicite. Les écosystèmes Python ou Rust, sans être invulnérables, ne déroulent pas ce tapis rouge à l'exécution de code tiers. Le règlement européen sur la cyberrésilience, dont les obligations de signalement s'appliquent à partir de septembre, achevait de rendre le statu quo indéfendable. En France, le CERT-FR avait consacré deux bulletins d'alerte aux vagues Shai-Hulud, en septembre puis en novembre derniers.
Pour les développeurs, le geste utile tient en une mise à jour : passer dès maintenant à npm 11.16.0 pour mesurer ce qui cassera. Les paquets à compilation native, les outils de hooks Git et quelques bibliothèques d'images protesteront en premier. Six semaines de réglages valent mieux qu'un portefeuille vide.
