En 2026, l'écosystème npm a traversé plusieurs incidents de sécurité qui ont forcé les mainteneurs d'outils à revoir leurs hypothèses de confiance. Le 31 mars, deux versions piégées d'axios — un paquet téléchargé environ 101 millions de fois par semaine — sont restées en ligne environ trois heures avant leur retrait, le temps d'installer un cheval de Troie d'accès distant chez les développeurs qui avaient lancé un npm install pendant la fenêtre. En juin, une autre attaque a visé l'écosystème Mastra AI en substituant la dépendance dayjs par un paquet cloné nommé easy-day-js : la première version publiée était propre, mais une mise à jour ultérieure a glissé un voleur de clés crypto dans un script postinstall, touchant plus de 140 paquets liés à @mastra.

Ces deux cas partagent un point commun : ils exploitent des angles morts que la plupart des gestionnaires de paquets laissent ouverts par défaut — l'exécution automatique de scripts de cycle de vie, la confiance immédiate accordée à une version qui vient d'être publiée, et la possibilité pour une dépendance transitive de pointer vers n'importe quelle source (dépôt git, tarball distant). Un audit de sécurité basé sur les CVE connues ne voit presque jamais venir ce type d'attaque : le paquet piégé est tout neuf, il n'a pas encore de rapport de vulnérabilité, et son code malveillant est souvent injecté plusieurs versions après la publication initiale — exactement le schéma suivi par easy-day-js. La version 10.26 de pnpm répond directement à ces angles morts avec trois réglages concrets que tu peux activer dès aujourd'hui dans pnpm-workspace.yaml.

Voici ce que fait chacun, pourquoi il existe, et comment le mettre en place sans casser ton pipeline d'installation.

minimumReleaseAge : ne jamais installer du code tout frais

Ce réglage, introduit dès la 10.16 et toujours présent en 10.26, impose un délai minimum entre la publication d'une version sur le registre et le moment où pnpm accepte de l'installer. La valeur s'exprime en minutes.

// pnpm-workspace.yaml
minimumReleaseAge: 1440 # 24h de quarantaine avant d'installer une nouvelle version

minimumReleaseAgeExclude:
  - '@mon-organisation/*' # tes propres paquets publiés, pas concernés

L'intérêt est direct : l'attaque axios a duré environ trois heures avant d'être neutralisée. Une quarantaine de 24h aurait tout simplement empêché la quasi-totalité des builds d'installer la version piégée, puisqu'elle aurait disparu du registre avant d'être « mûre ». C'est la même logique que la mise en quarantaine des mises à jour système : un code qui vient de sortir n'a pas encore eu le temps d'être repéré comme malveillant par la communauté ou les outils de scan automatisés. minimumReleaseAgeExclude te permet d'exempter tes propres scopes internes, pour ne pas te bloquer toi-même quand tu publies une correction urgente.

allowBuilds : un seul endroit pour autoriser les scripts d'installation

Avant la 10.26, le contrôle des scripts preinstall/install/postinstall se répartissait sur plusieurs réglages — onlyBuiltDependencies, ignoredBuiltDependencies, neverBuiltDependencies. pnpm les unifie dans une seule carte, allowBuilds, qui associe un nom de paquet (ou un motif) à true ou false :

// pnpm-workspace.yaml
allowBuilds:
  esbuild: true          # script d'installation légitime, connu
  '@mon-scope/*': true   # tes paquets internes
  'nx@21.6.0': false     # une version précise que tu veux bloquer
  '*': false             # tout le reste : scripts d'installation désactivés

Tu n'as pas besoin de remplir cette carte à la main : la commande pnpm approve-builds te présente la liste des paquets qui tentent d'exécuter un script au moment de l'install, et écrit ton choix directement dans allowBuilds. C'est exactement le scénario qui aurait limité la casse sur le postinstall malveillant de easy-day-js : si le paquet n'a jamais figuré dans ta liste d'autorisations, son script ne s'exécute pas, qu'il soit malveillant ou pas.

Autre changement notable de cette version : les dépendances hébergées sur git ne peuvent plus exécuter de script prepare pendant l'installation, sauf autorisation explicite via allowBuilds (ou l'ancien onlyBuiltDependencies). C'est important si ton projet dépend de forks ou de paquets non publiés sur le registre officiel.

À noter si tu suis les versions alpha : pnpm 11 (encore en phase alpha au moment de l'écriture) supprime purement et simplement onlyBuiltDependencies, onlyBuiltDependenciesFile, neverBuiltDependencies, ignoredBuiltDependencies et ignoreDepScripts au profit du seul allowBuilds. Un codemod de migration est fourni (pnpx codemod run pnpm-v10-to-v11) pour convertir automatiquement tes anciens réglages.

blockExoticSubdeps : fermer la porte aux sources exotiques en transitif

Le troisième réglage cible un vecteur plus discret : une dépendance transitive (celle qu'une de tes dépendances directes installe elle-même, sans que tu la voies dans ton package.json) peut, par défaut, pointer vers une source dite « exotique » — une URL git+ssh, un tarball distant, un dépôt GitHub arbitraire — plutôt que vers le registre npm classique. C'est une porte d'entrée que les attaques de type ver (comme la vague « Shai-Hulud » observée en avril 2026, qui s'est propagée sur npm et PyPI via des jetons de publication volés) peuvent exploiter pour injecter un paquet de remplacement en profondeur dans l'arbre de dépendances, loin des yeux du développeur.

// pnpm-workspace.yaml
blockExoticSubdeps: true

Une fois activé, seules tes dépendances directes — celles listées explicitement dans le package.json à la racine — peuvent encore utiliser une source exotique. Tes dépendances transitives, elles, sont forcées de passer par le registre configuré, un chemin local, un lien de workspace, ou une poignée de dépôts GitHub de confiance (node, bun, deno) et de résolveurs personnalisés déjà whitelistés par pnpm. Concrètement : si une dépendance de tes dépendances tente discrètement de basculer sur un tarball hébergé ailleurs, l'installation échoue au lieu de se faire en silence.

Mettre ça en place sans tout casser

Ces trois réglages sont indépendants, mais ils couvrent des moments différents de la chaîne d'installation : l'âge de la version, l'exécution de scripts, et la provenance des paquets. L'ordre d'adoption le plus pragmatique, en particulier sur un monorepo existant :

Lance pnpm approve-builds sur ton projet actuel pour générer une première carte allowBuilds à partir de ce qui tourne déjà — tu pars d'un état qui fonctionne, pas d'une interdiction totale qui casse ton build.
Ajoute minimumReleaseAge avec une valeur modeste pour commencer (360 à 1440 minutes selon ta tolérance), et exclus tes propres scopes internes via minimumReleaseAgeExclude pour ne pas te pénaliser toi-même.
Active blockExoticSubdeps: true seulement si un audit rapide de ton pnpm-lock.yaml confirme que tu ne dépends pas de paquets transitifs tirés directement d'un dépôt git ou d'un tarball — sinon, commence par corriger ces dépendances avant d'activer le blocage.
Teste ces réglages dans une branche CI dédiée avant de les imposer sur main : un allowBuilds trop restrictif casse silencieusement des builds natifs (comme ceux qui dépendent d'esbuild ou de node-gyp) si tu oublies une entrée.

Rien de tout ça ne remplace un audit de dépendances régulier ou une politique de jetons de publication à durée de vie courte côté mainteneur. Mais sur ton poste de développeur et dans ta CI, ces trois lignes de configuration ferment exactement les portes par lesquelles sont passées les attaques qui ont marqué 2026 : le script qui s'exécute sans qu'on l'ait demandé, la version qui vient de sortir et qu'on installe sans attendre, et la dépendance transitive qui va chercher son code ailleurs que là où on le croit.

Le détail qui compte pour l'adoption en équipe : ces réglages vivent dans pnpm-workspace.yaml, un fichier versionné et partagé par tout le monorepo, pas dans une configuration locale au poste de chaque développeur. Une fois le fichier commité, la protection s'applique automatiquement à chaque pnpm install lancé par un collègue ou par ta CI, sans action manuelle de leur part. C'est ce qui rend ces trois réglages réellement utilisables à l'échelle d'une équipe, plutôt qu'une bonne pratique que chacun doit se rappeler d'activer de son côté.

pnpm 10.26 face aux attaques supply-chain npm de 2026