En bref

  • GitHub a annoncé le 9 juin 2026 que npm v12, attendu en juillet, désactivera par défaut l'exécution automatique des scripts d'installation, mettant fin à l'un des vecteurs d'attaque les plus exploités dans les campagnes de compromission de la chaîne logicielle JavaScript.
  • Trois modifications majeures affectent les projets utilisant des scripts preinstall/install/postinstall, des dépendances Git ou des packages provenant d'URL distantes.
  • Les équipes de développement doivent auditer leurs dépendances dès maintenant et migrer vers npm 11.16.0 pour identifier les impacts avant la mise à jour en production.

npm v12 met fin à une décennie d'abus des scripts d'installation

GitHub a publié le 9 juin 2026 une annonce technique détaillant trois changements majeurs introduits dans npm v12, la prochaine version majeure du gestionnaire de paquets JavaScript le plus utilisé au monde. Ces modifications, qualifiées de breaking changes par l'équipe npm, représentent la réforme de sécurité la plus significative apportée à npm depuis sa création, et visent à neutraliser une classe entière d'attaques contre la chaîne d'approvisionnement logicielle (supply chain) qui sévit depuis des années dans l'écosystème JavaScript.

Le changement central concerne les scripts d'installation automatiques. Jusqu'à présent, lorsqu'un développeur exécutait la commande npm install, npm exécutait automatiquement, pour chaque dépendance installée, les scripts définis dans les champs preinstall, install et postinstall du fichier package.json. Cette fonctionnalité, conçue à l'origine pour permettre aux mainteneurs de paquets de compiler des modules natifs ou de configurer leur environnement lors de l'installation, est devenue au fil des années le mécanisme favori des acteurs malveillants pour faire exécuter du code arbitraire sur la machine du développeur sans son consentement explicite.

Dès le premier npm install, un paquet malveillant pouvait lire les variables d'environnement contenant des secrets (tokens d'API, clés AWS, tokens GitHub), exfiltrer le contenu du répertoire .ssh, installer des backdoors persistants ou télécharger et exécuter des binaires supplémentaires. Toutes ces opérations se produisaient de manière totalement transparente pour le développeur, qui ne voyait qu'une longue liste de paquets s'installer. Les campagnes TrapDoor de mai 2026, qui ciblaient spécifiquement les développeurs crypto et IA via 34 packages piégés, exploitaient précisément ce mécanisme.

À partir de npm v12, ces scripts ne s'exécuteront plus automatiquement. Les développeurs devront explicitement autoriser l'exécution de scripts pour chaque dépendance qui en requiert, via une liste blanche de confiance. Le modèle de sécurité passe ainsi d'une confiance implicite — tout ce qui est installé est autorisé à s'exécuter — à un consentement explicite, aligné sur le principe du moindre privilège.

Le deuxième changement concerne les dépendances Git. npm permettait jusqu'ici de spécifier des dépendances directement depuis un dépôt Git, une fonctionnalité pratique pour les forks ou les modules non publiés sur le registre npm. Cette capacité a été massivement abusée par des attaquants qui empoisonnaient des dépôts Git légitimes ou créaient des dépôts usurpant le nom de bibliothèques populaires. Dans npm v12, l'option --allow-git sera désactivée par défaut (valeur none), bloquant toute résolution de dépendance via des URLs Git sauf activation explicite.

Le troisième changement s'attaque aux dépendances distantes par URL. Certains développeurs ou outils de build référençaient des packages directement via des URLs HTTPS vers des archives tarball. Cette pratique, pouvant contourner les contrôles de sécurité du registre npm officiel — qui inclut une analyse de malware, une vérification de provenance et un système de signalement — sera également désactivée par défaut via l'option --allow-remote définie sur none.

Pour faciliter la transition, GitHub recommande aux équipes de migrer vers npm 11.16.0 (ou toute version entre 11.10.0 et 11.16.0), qui intègre déjà un mécanisme d'avertissement permettant d'identifier, avant la mise à jour vers v12, quelles dépendances existantes utilisent des scripts d'installation, des sources Git ou des URLs distantes. Cette migration préventive est particulièrement critique pour les pipelines d'intégration continue (CI/CD), où un changement non anticipé de npm pourrait bloquer des builds en production.

GitHub n'a pas communiqué de date de sortie précise pour npm v12, indiquant simplement que la version finale est attendue pour juillet 2026. La publication de ces breaking changes deux mois à l'avance est précisément destinée à laisser aux équipes le temps d'auditer leurs dépendances et d'ajuster leurs configurations. Plusieurs grands projets open source — dont des frameworks populaires du monde JavaScript — ont déjà signalé avoir des dépendances utilisant des scripts d'installation pour la compilation de modules natifs (N-API, node-gyp), qui devront être explicitement whitelistées dans la nouvelle configuration.

Un changement culturel autant que technique pour l'écosystème JavaScript

La décision de GitHub de désactiver les scripts d'installation par défaut représente bien plus qu'un changement technique. Elle matérialise un changement de paradigme culturel dans un écosystème JavaScript qui s'est longtemps distingué par une permissivité extrême vis-à-vis de l'exécution de code lors de l'installation de packages. Le registre npm héberge plus de 2,5 millions de packages au second semestre 2026, et npm est exécuté par des centaines de millions de développeurs dans le monde. La surface d'attaque qu'il représente est considérable.

Les incidents passés illustrent l'ampleur du problème. En 2021, le package colors.js avait introduit une boucle infinie dans sa propre codebase, affectant des milliers d'applications. En 2022, le package node-ipc avait inclus du code malveillant ciblant les développeurs russes et biélorusses. Plus récemment, la campagne TrapDoor de mai 2026 avait ciblé des développeurs IA et crypto avec des packages spécifiquement conçus pour dérober des secrets d'environnement. Chacun de ces incidents a exploité la même faiblesse fondamentale : la confiance implicite accordée au code exécuté lors de npm install.

Pour les organisations ayant des pratiques de développement sécurisé (DevSecOps) matures, ce changement sera relativement transparent : elles utilisent déjà des outils comme Socket.dev, Snyk ou Dependabot pour analyser les scripts d'installation suspects, et leurs politiques internes limitent déjà les dépendances aux packages du registre officiel avec vérification de provenance. Pour les organisations moins matures, ce changement forcé représente une opportunité d'assainir leur portefeuille de dépendances avant juillet.

La mesure s'inscrit dans une tendance de fond de durcissement des gestionnaires de paquets. Python's pip avait restreint ses capacités d'exécution de scripts en 2023. La communauté Rust impose une déclaration explicite des scripts de build depuis les premières versions de Cargo. npm, historiquement le plus permissif des gestionnaires de paquets modernes, comble ici un écart significatif avec ses concurrents en matière de sécurité par défaut. Le message de l'industrie est clair : la confiance implicite dans le code installé n'est plus tenable à l'ère des attaques supply chain industrialisées.

Ce qu'il faut retenir

  • Mettre à jour npm vers la version 11.16.0 immédiatement pour identifier les dépendances qui utilisent des scripts d'installation, des sources Git ou des URLs distantes avant la transition vers npm v12 en juillet 2026.
  • Auditer le fichier package.json et les lock files de tous vos projets JavaScript pour recenser les dépendances concernées et décider lesquelles méritent une autorisation explicite.
  • Mettre à jour les pipelines CI/CD en ajoutant les flags d'autorisation explicites requis par npm v12 pour les dépendances légitimes nécessitant la compilation de modules natifs.

Mes builds CI/CD vont-ils être impactés par npm v12 ?

Si vos dépendances utilisent des scripts preinstall, install ou postinstall — cas fréquent avec des modules comme node-sass, bcrypt ou sqlite3 qui compilent du code natif — oui. La migration vers npm 11.16.0 affichera des avertissements pour chaque dépendance concernée. Vous devrez ensuite ajouter un fichier .npmrc ou un flag en ligne de commande pour explicitement autoriser ces scripts, par exemple avec l'option --allow-scripts pour les packages validés par votre équipe de sécurité.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact