Tech-Connect Tech-Connect est un site web proposant des actualités, des tutoriels, des astuces et un forum dans le domaine technologique, informatique, science, télécommunications, mobile, tablette, windows, mac os, linux, opensource, android et IOS. 
Le 9 juin 2026, GitHub a publié une annonce discrète dans son historique des modifications qui a fait l’effet d’une petite bombe dans la communauté JavaScript mondiale.
npm v12, la prochaine version majeure du plus grand gestionnaire de paquets du monde, va désactiver par défaut les scripts automatiques lors de l’installation. Ce changement semble technique et anodin. Il ne l’est pas. C’est l’une des transformations de sécurité les plus significatives dans l’histoire de l’écosystème JavaScript, une décision qui répond à une décennie d’attaques supply chain qui ont coûté des milliards de dollars à des entreprises dans le monde entier.
Dans cet article, on explique ce changement de fond en comble. Pas seulement pour les développeurs, mais pour toute personne qui utilise ou finance un produit logiciel construit avec du JavaScript, c’est-à-dire potentiellement tout le monde.
npm et les scripts d’installation
Avant d’entrer dans le vif du sujet, posons les bases pour que tout le monde soit à bord. Qu’est-ce que npm et qu’est-ce qu’un script d’installation ?
npm : le supermarché des briques logicielles
npm (Node Package Manager) est une plateforme en ligne qui héberge des millions de petits morceaux de code JavaScript, appelés packages ou paquets. Quand un développeur construit une application web (un site e-commerce, une application mobile, un outil interne d’entreprise) il n’écrit pas tout le code depuis zéro. Il installe des packages préexistants qui font des choses précises : envoyer des emails, gérer des images, compresser des vidéos, authentifier des utilisateurs, etc.
La commande magique pour tout ça est npm install. Vous tapez ces deux mots dans votre terminal, et npm va sur internet, télécharge tous les packages dont votre projet a besoin, et les installe automatiquement. Des centaines, parfois des milliers de packages, en quelques secondes. C’est incroyablement pratique.
📦 Imaginez que vous construisez une maison. Plutôt que de fabriquer vous-même chaque brique, chaque tuyau et chaque interrupteur, vous les commandez au supermarché du bâtiment. npm, c’est ce supermarché mais pour le code JavaScript. Et npm install, c’est votre commande de livraison express.
Les scripts d’installation : du code qui s’exécute sans vous demander
Là où ça devient intéressant et problématique, c’est avec les scripts d’installation. De nombreux packages ont besoin d’effectuer des actions pendant leur installation : compiler du code natif, télécharger des fichiers supplémentaires, configurer des variables d’environnement, créer des dossiers. Pour ça, npm leur permet d’inclure des scripts qui s’exécutent automatiquement à différents moments du processus d’installation.
- preinstall : s’exécute AVANT l’installation du package.
- install : s’exécute PENDANT l’installation.
- postinstall : s’exécute APRÈS l’installation, le plus utilisé et le plus abusé
Ces scripts peuvent faire pratiquement n’importe quoi sur votre machine. Écrire des fichiers. Se connecter à internet. Lire vos variables d’environnement (qui contiennent souvent des mots de passe et des clés API). Exécuter des commandes système. Jusqu’à npm v12, tout ça se passait automatiquement, sans vous demander la permission, dès que vous tapiez npm install.
🚨 Jusqu’à présent, installer un package npm revenait à donner les clés de votre appartement à un inconnu en lui disant ‘installez ce truc dans le salon, fais attention’. Il pouvait se servir dans le frigo, copier des documents sur la table, ou laisser une porte dérobée.
Le problème de sécurité que npm v12 résout enfin
Les scripts d’installation automatiques sont le vecteur d’attaque le plus utilisé dans les attaques supply chain JavaScript depuis des années. L’échelle du problème en 2025 et 2026 est véritablement alarmante.
| Statistique | Valeur | Source |
| Packages malveillants publiés sur npm en 2025 | ~455 000 | Étude sécurité 2026 |
| Attaque Miasma (juin 2026) : packages Red Hat infectés | 32 puis +57 | Wiz Research, Snyk |
| Attaque Phantom Gyp (3 juin 2026) : repos Azure touchés | 73 repositories | ByteIOTA |
| Heure nécessaire pour les 73 repos Azure | 105 secondes | ByteIOTA |
| Coût moyen d’une attaque supply chain réussie | $1,1 million USD | IBM Security 2025 |
Le raisonnement est simple : si vous pouvez publier un package avec un script postinstall malveillant, et que npm exécute ce script automatiquement sur la machine de tout développeur qui installe votre package, vous avez accès à ses identifiants AWS, ses tokens GitHub, ses clés SSH et potentiellement à tous les systèmes auxquels sa machine a accès.
Ce qui est particulièrement pernicieux dans cette attaque, c’est sa propagation en cascade. Un package infecté peut, dans son script postinstall, chercher d’autres packages que le développeur maintient et y publier des versions infectées à leur tour. Un seul développeur compromis peut infecter des centaines de packages. Les victimes de ces packages infectés contaminent à leur tour d’autres projets. C’est la définition d’un ver informatique et c’est exactement ce que faisait Miasma.
Le rôle de l’attaque Miasma et du Phantom Gyp dans le timing de npm v12
Pourquoi npm v12 arrive-t-il en juillet 2026 et pas avant ? Parce que la pression des événements récents a rendu l’inaction politiquement impossible.
Miasma : Le ver qui a touché Red Hat en temps réel
Le 1er juin 2026, l’attaque Miasma a infecté 32 packages officiels de Red Hat sous le namespace @redhat-cloud-services sur npm. Le malware utilisait précisément les scripts preinstall pour s’exécuter et voler des identifiants AWS, tokens GitHub, clés SSH, et accès Kubernetes dès qu’un développeur faisait npm install. On a décrit cet incident en détail dans notre article dédié sur Miasma.
Deux jours plus tard, une deuxième vague plus sournoise est arrivée : le Phantom Gyp.
Phantom Gyp : L’attaque que –ignore-scripts ne bloquait pas
C’est là que ça devient diabolique. Le Phantom Gyp est une technique qui exploite une faille dans npm lui-même, pas dans le code d’un package malveillant. Voici comment ça fonctionne.
npm a une fonctionnalité pour compiler du code natif (C/C++) : si un package contient un fichier appelé binding.gyp, npm déclenche automatiquement un rebuild en C++ via l’outil node-gyp. Ce comportement est conçu pour les packages légitimes qui ont besoin de performance native (chiffrement, traitement d’images, etc.). Et c’est automatique, même si vous utilisez –ignore-scripts, qui était la protection habituelle contre les scripts malveillants.
L’attaque Phantom Gyp place simplement un minuscule fichier binding.gyp (157 octets) dans un package compromis. npm voit le fichier, exécute automatiquement node-gyp rebuild, et le code malveillant s’exécute. Résultat : le 3 juin 2026, cette technique a compromis 73 dépôts Microsoft Azure en 105 secondes. –ignore-scripts n’a rien vu passer.
🎯 C’est cette attaque qui a forcé la main de GitHub. Quand –ignore-scripts, la protection que tout le monde recommandait, ne protège plus, il faut changer l’architecture de fond. npm v12 bloque le Phantom Gyp directement.
Les 3 changements précis de npm v12
npm v12 introduit trois changements majeurs, tous dans la même direction : passer d’un modèle de confiance implicite (tout s’exécute par défaut) à un modèle de confiance explicite (rien ne s’exécute sauf ce que vous approuvez).
Changement #1 : allowScripts passe à off (le plus impactant)
C’est le changement principal. À partir de npm v12, npm install ne lancera plus les scripts preinstall, install ou postinstall d’aucune dépendance, sauf si vous les avez explicitement autorisés.
# Avant npm v12 (comportement actuel) :
npm install # → exécute TOUS les scripts de TOUTES les dépendances
# Avec npm v12 (nouveau comportement par défaut) :
npm install # → n’exécute AUCUN script, sauf ceux de votre allowlist
Pour autoriser un script spécifique, vous avez deux options. Soit la commande interactive :
npm approve-scripts [email protected]Soit directement dans votre package.json en ajoutant un champ allowScripts :
{
"allowScripts": {
"[email protected]": true,
"[email protected]": true,
"node-gyp": true
}
}⚠️ Point crucial sur la version utilisée : autoriser [email protected] n’autorise PAS [email protected]. Chaque mise à jour de version nécessite une nouvelle approbation manuelle. C’est intentionnel, un attaquant qui publie une version vérolée d’un package ne peut plus se glisser sous la protection de votre allowlist existante.
Changement #2 : Git dependencies bloquées par défaut
Vous avez peut-être l’habitude d’installer des packages directement depuis GitHub, comme ça :
npm install github:owner/repo
À partir de npm v12, ces dépendances Git sont bloquées par défaut. La raison : un dépôt GitHub peut être compromis (comme l’ont montré les attaques via OIDC sur les GitHub Actions), et y installer directement un package bypass toutes les vérifications habituelles du registre npm. Pour les autoriser, il faudra explicitement déclarer allowGit dans votre configuration.
Changement #3 : Remote URL dependencies bloquées
De même, les installations directement depuis une URL distante (type npm install https://example.com/package.tgz) seront bloquées par défaut. Même logique : une URL distante peut pointer vers n’importe quoi, sans les garanties de provenance et d’intégrité du registre npm officiel.
| Comportement | Avant npm v12 | Après npm v12 | Pour l’activer |
| Scripts preinstall/install/postinstall | ✅ Auto | ❌ Bloqué | allowScripts: true dans package.json |
| node-gyp rebuild automatique | ✅ Auto | ❌ Bloqué | allowScripts: true pour le package |
| prepare scripts (git/file deps) | ✅ Auto | ❌ Bloqué | allowScripts dans la config |
| Dépendances GitHub (git:) | ✅ Auto | ❌ Bloqué | allowGit: true dans la config |
| Dépendances URL distantes | ✅ Auto | ❌ Bloqué | allowRemote: true dans la config |
Ce qui va concrètement casser dans votre projet
C’est la question que tous les développeurs se posent. La réponse honnête : probablement plus de choses que vous ne le pensez, parce que beaucoup de packages utilisent des scripts d’installation de façon invisible.
Packages qui utilisent des scripts légitimes
De nombreux packages populaires et tout à fait légitimes ont besoin de leurs scripts d’installation pour fonctionner correctement. Parmi les plus courants :
- esbuild – le bundler JavaScript ultra-rapide : son binaire natif est compilé via postinstall.
- sharp – traitement d’images : compile des liaisons libvips en C++ au moment de l’installation.
- canvas – rendu canvas Node.js : compile des liaisons Cairo.
- bcrypt – hachage de mots de passe sécurisé : compile des liaisons en C.
- node-sass / sass – compilation SCSS vers CSS : compile des liaisons C++.
- Prisma – ORM populaire : génère le client typé en postinstall.
- Husky – git hooks : configure les hooks via prepare.
- Tout package avec un fichier binding.gyp déclenche node-gyp automatiquement.
Ces packages continueront de fonctionner avec npm v12, mais vous devrez les ajouter explicitement à votre allowlist. Ce qu’il ne se passera plus, c’est que leur script s’exécute en silence sans votre accord.
Comment détecter maintenant ce qui va casser
La bonne nouvelle : npm 11.16.0 (déjà disponible) intègre tous les changements de v12 en mode avertissement. Ça signifie que vous pouvez tester dès aujourd’hui sans attendre juillet.
# Mettez à jour npm vers 11.16.0 ou supérieur :
npm install -g npm@latest# Dans votre projet, lancez npm install :
npm install# → npm affichera des avertissements pour chaque script qui sera bloqué en v12
Faites ça sur votre projet principal et notez tout ce qui apparaît en avertissement. Chaque avertissements est un script qui cassera quand npm v12 arrivera.
Guide de migration : Ce que vous devez faire avant juillet 2026
Étape 1 – Inventaire : que s’exécute-t-il dans mon npm install ?
- Mettez à jour npm : npm install -g npm@latest
- Dans votre projet, lancez : npm install –foreground-scripts 2>&1 | grep warn
- Listez tous les packages qui déclenchent des avertissements
- Pour chaque package, vérifiez : son script est-il légitime ? Que fait-il exactement ?
Étape 2 – Construire votre allowlist (liste autorisée)
Une fois votre inventaire fait, ajoutez les packages légitimes à votre allowlist dans package.json :
{
"name": "mon-projet",
"allowScripts": {
"[email protected]": true,
"[email protected]": true,
"[email protected]": true,
"[email protected]": true,
"@prisma/[email protected]": true
}
}Étape 3 – Approuver interactivement avec npm approve-scripts
Pour une première migration, la commande approve-scripts vous guide de façon interactive :
npm approve-scripts --allow-scripts-pending# → npm liste chaque script en attente et vous demande : Allow? (y/N)
# → Pour chaque package, npm affiche le code du script pour que vous puissiez l’inspecter
Étape 4 : Mettre à jour votre pipeline CI/CD
Dans votre fichier de pipeline (GitHub Actions, GitLab CI, Jenkins…), si vous avez des étapes npm install, elles continueront de fonctionner si votre allowlist est bien définie dans package.json. Mais si vous avez des scripts qui s’exécutent implicitement sans être dans l’allowlist, votre build va casser.
⏰ Échéance : npm v12 est prévu pour juillet 2026. Vous avez environ 2-4 semaines pour auditer et mettre à jour vos projets.
Packages les plus touchés : Guide de référence rapide
| Package | Usage | Impact v12 | Action nécessaire |
| esbuild | Bundler JavaScript rapide | Binaire natif ne compile plus | allowScripts: { ‘[email protected]’: true } |
| sharp | Traitement d’images | Liaisons libvips cassées | allowScripts: { ‘[email protected]’: true } |
| canvas | Rendu canvas | Liaisons Cairo cassées | allowScripts: { ‘[email protected]’: true } |
| bcrypt | Hash mots de passe | Liaisons C++ cassées | allowScripts: { ‘[email protected]’: true } |
| Prisma | ORM base de données | postinstall generate cassé | allowScripts: { ‘@prisma/client’: true } |
| Husky | Git hooks pre-commit | prepare cassé | allowScripts: { ‘husky@x’: true } |
| node-sass | Compilation SCSS | Liaisons C++ cassées | allowScripts ou migrer vers sass |
| Tout package binding.gyp | Code natif C/C++ | node-gyp rebuild bloqué | allowScripts avec le nom exact + version |
pnpm et Yarn l’avaient déjà
Une question revient constamment dans les commentaires des développeurs depuis l’annonce : pourquoi npm a-t-il mis si longtemps ? pnpm, l’alternative de plus en plus populaire au npm classique, a introduit le blocage des scripts par défaut il y a plus de 18 mois. Yarn 4 a une approche similaire depuis 2023.
La réponse est dans la taille de l’écosystème. npm héberge plus de 2,5 millions de packages et est utilisé par des centaines de millions de développeurs. Changer le comportement par défaut dans npm, c’est risquer de casser des pipelines CI/CD dans des milliers d’entreprises simultanément. C’est un changement à fort impact potentiel, ce qui explique la prudence historique.
Ce qui a changé la donne en 2026, c’est la pression accumulée des incidents : Miasma, Phantom Gyp, le bilan de 455 000 packages malveillants en 2025. À un moment, continuer à protéger la commodité au détriment de la sécurité devient intenable surtout quand les alternatives (pnpm, Yarn 4) démontrent que le modèle restrictif est viable.
💡 Si vous cherchez à anticiper ces changements encore plus vite : pnpm (pnpm.io) a déjà ce comportement par défaut depuis 2025. Migrer de npm à pnpm est moins compliqué que ça n’y paraît, et vous met déjà en sécurité sans attendre juillet.
Ce que npm v12 ne résout PAS
La communauté de sécurité accueille npm v12 positivement. Mais certains experts soulèvent une critique légitime : ces changements sont nécessaires mais insuffisants.
- Le registre npm n’analyse toujours pas les packages avant publication : n’importe qui peut publier un package malveillant en quelques secondes, sans aucune vérification de contenu.
- Les typosquatters (packages avec des noms similaires aux vrais) restent une menace, npm v12 ne les bloque pas.
- Les packages déjà installés dans votre node_modules ne sont pas re-vérifiés.
- Les scripts dans vos propres package.json (vos scripts à vous, pas les dépendances) restent inchangés.
- Un attaquant qui réussit à compromettre le registre npm lui-même (et pas juste un package) peut toujours distribuer du code malveillant.
La plateforme OpenSource Malware l’a bien résumé : npm v12 résout un problème spécifique qui représentait 80% des vecteurs d’attaque. C’est une victoire majeure. Mais ce n’est pas la fin de la supply chain security, c’est le début d’une nouvelle ère où d’autres vecteurs prendront le relais.
- Recommandation complémentaire : activez aussi min-release-age dans npm 11.10.0+ (ne pas installer une version publiée il y a moins de X jours), c’est l’une des protections les plus efficaces contre les attaques opportunistes.
