La Provenance n'est pas une Preuve : Ce qu'il faut vérifier avant d'exécuter `npm install -g` pour un Tunnel CLI

Deux choses sont vraies en novembre 2026. npm 12 refuse désormais d’exécuter par défaut les scripts d’installation des dépendances, ce qui ferme le chemin de livraison le plus courant de la chaîne d’approvisionnement. Et dans la même année, des attaquants ont diffusé des versions malveillantes de npm qui portaient des attestations de provenance valides, plus des charges utiles qui ne touchent même pas à un script d’installation.

Si vous êtes sur le point d’exécuter npm install -g sur un client Tunnel, les deux faits comptent. Un tunnel CLI est un processus longue durée qui détient un jeton d’authentification, hérite des variables d’environnement de votre shell et relaie le trafic entre l’internet public et votre localhost. Ce guide couvre ce que npm 12 change, ce que la provenance prouve et ne prouve pas, et une liste de vérification pré-install : verrouillage des versions, ignore-scripts, binaires autonomes vérifiés par somme de contrôle et des listes d’autorisation d’egress.

Pourquoi un client tunnel est une cible de grande valeur

Un client tunnel s’exécute pendant des heures ou des jours, avec les privilèges de votre utilisateur, sur la machine où vivent vos fichiers de code, vos clés et vos fichiers .env, et sur un chemin réseau où une copie modifiée pourrait lire tout ce qu’elle relaie. Le compte rendu de Palo Alto Networks sur la libération piratée de @bitwarden/cli énumère les cibles : clés SSH, tokens .npmrc, fichiers .env, identifiants AWS, configurations Git, tokens GitHub CLI, jetons d’authentification npm et configurations IA/MCP. Le jeton d’authentification du client tunnel serait naturellement adjacent à ces éléments, et un processus déjà doté d’une connectivité sortante est bien placé pour l’envoyer quelque part.

Ce que npm 12 a changé, et ce qu’il n’a pas changé

GitHub a annoncé npm 12 en juillet 2026, avec allowScripts désactivé par défaut. Selon The Hacker News, les scripts preinstall, install et postinstall des dépendances, et les builds implicites node-gyp ne s’exécutent plus à moins d’être explicitement autorisés. Les dépendances Git et les tarballs URL distants sont aussi désactivés sauf si vous activez avec --allow-git ou --allow-remote. L’avis de modification du changelog de GitHub date du 9 juin 2026.

Trois conséquences pratiques pour les tunnels CLIs :

• Les paquets wrapper qui téléchargent un binaire au moment de l’installation cessent de le faire. Le wrapper Node.js pour ngrok indique que npm install télécharge le binaire de la plateforme à partir de l’hébergement de ngrok lors de l’étape postinstall. Sous npm 12, ce téléchargement est bloqué jusqu’à ce que vous l’approuviez. C’est une fonctionnalité : elle vous force à décider si vous faites confiance à ce chemin de téléchargement.
• Les installations globales nécessitent un drapeau, pas une liste d’autorisation. Des rapports sur le tracker CLI npm montrent que pour npm install -g, l’avertissement vous dirige vers npm install -g --allow-scripts=<pkg>, ou npm config set allow-scripts=<pkg> --location=user pour le persister. Un article communautaire note aussi que npm approve-scripts échoue pour les installations globales, une lacune connue.
• Les versions plus anciennes de npm nécessitent toujours ignore-scripts. La demande de tirage npm qui a inversé le comportement par défaut conserve ignore-scripts=true comme solution de repli pour les versions plus anciennes. Gardez-le dans votre configuration jusqu’à ce que chaque appareil de votre parc exécute npm 12.

Le vide : les charges utiles qui s’exécutent lorsque le code s’exécute

Bloquer les scripts d’installation ne fait rien contre le code qui s’exécute lorsque le paquet est utilisé. L’analyse de Microsoft de juillet 2026 sur la compromission AsyncAPI a trouvé une charge utile déclenchée au chargement du module, et elle indiquait que --ignore-scripts ne neutralisait pas ce schéma. Les rapports sur l’incident indiquent que quatre paquets @asyncapi ont été trojanisés, y compris @asyncapi/specs, qui compte environ 2,66 millions de téléchargements hebdomadaires.

Le cas Bitwarden CLI illustre le même angle mort. La version malveillante 2026.4.0, publiée le 22 avril 2026, a réorienté à la fois un hook preinstall et l’entrée binaire bw vers un script de chargement. Une analyse OpenReplay souligne que l’entrée bin signifiait que la charge utile s’exécutait encore chaque fois que quelqu’un invoquait la commande, même avec --ignore-scripts activé.

Appliquez cela à un CLI global. Vous l’installez précisément pour pouvoir l’exécuter. Pour un client tunnel, la frontière entre « installé » et « exécuté » est d’une commande, donc le blocage des scripts vous apporte moins que pour un arbre de dépendances frontal. Cela reste utile à avoir. Ce n’est pas suffisant.

Provenance : ce qu’elle prouve et ce qu’elle ne prouve pas

La provenance npm lie un paquet publié au dépôt source et aux instructions de build qui l’ont produit. La documentation propre de npm est explicite sur la limite : la provenance ne garantit pas l’absence de code malveillant. Elle vous donne un enregistrement vérifiable à auditer, pas un verdict.

En 2026, trois démonstrations claires ont été fournies.

Date	Incident	Ce qui portait une provenance valide
11 mai 2026	TanStack worm : 84 versions malveillantes réparties sur 42 paquets @tanstack/*	Publié à partir du pipeline de publication de confiance réel après le vol d’un jeton OIDC
9 septembre 2026	GHAPPIER : @dforge-core/dforge-mcp@0.2.21	Construit par GitHub Actions via publication de confiance OIDC ; l’attestation nomme le commit de l’attaquant
Octobre 2026	faille “Slugfest” de publication de confiance : 1 500+ paquets exposés	Une release d’un dépôt revendiquant un nom abandonné transporterait aussi une attestation valide

Dans l’incident TanStack, Unit 42 de Palo Alto le décrit comme le premier ver documenté à publier des paquets malveillants avec une provenance SLSA Build Level 3 valide, et résume le problème ainsi : la provenance confirme quel pipeline a construit un paquet, non si ce pipeline était propre. Son analyse ajoute que l’association publisher de confiance couvrait l’ensemble du dépôt plutôt qu’un seul workflow sur une branche protégée.

GHAPPIER fait le même point par une porte différente. CloudSEK rapporte qu’un attaquant a utilisé l’accès d’un mainteneur pendant environ 105 minutes, modifié le workflow de publication pour que les pushes soient publiés automatiquement, et livré la version 0.2.21, qui est restée la dernière version pendant environ 35 minutes. Comme le registre a fait confiance à l’identité CI du référentiel, la release aurait passé les npm audit signatures.

Les recherches Slugfest de Bloom Security ont montré que toute personne qui enregistrait un nom de dépôt GitHub qu’un mainteneur avait abandonné pouvait publier vers des paquets qui lui faisaient encore confiance. GitHub affirme avoir publié des correctifs, et les configurations non validées expirent désormais après 48 heures. Le conseil de Bloom aux consommateurs : vérifiez que l’attestation nomme le dépôt d’où provient le projet.

L’absence de provenance demeure un signal

Rien de tout cela ne rend la provenance inutile. Un article sur l compromission axios du 31 mars 2026 note que les versions malveillantes manquaient de la provenance GitHub Actions que les versions légitimes avaient, ce qui était un signal de détection clé. Une analyse de sécurité de Mondoo ajoute une mise en garde connexe : rien n’empêche d’installer une version qui a perdu la provenance. Donc la règle est : une attestation manquante ou mal assortie est une raison d’arrêter ; une attestation valide est une raison de continuer à vérifier.

La liste de vérification pré-installation

1. Confirmer l’identité et verrouiller une version exacte

Vérifiez le nom du paquet, l’étendue et la version par rapport à la documentation du fournisseur. L’analyse de JFrog indique que la version hijackée Bitwarden, 2026.4.0, n’existe pas dans l’historique réel des versions, malgré des métadonnées qui semblent légitimes. Puis verrouillez ce que vous avez vérifié au lieu d’installer @latest :

npm install -g some-tunnel-cli@1.2.3

3. Ajouter une porte d’âge de version

npm 11.10 (février 2026) a ajouté min-release-age, mesuré en jours. Les versions malveillantes sont souvent détectées et retirées en quelques heures. La version défectueuse de GHAPPIER était la plus récente pendant environ 35 minutes, et la fenêtre Bitwarden a été signalée à environ une heure et demie. Une porte d’âge de sept jours aurait permis d’éviter les deux.

# ~/.npmrc
min-release-age=7
ignore-scripts=true

Deux particularités documentées par les utilisateurs : npm config get min-release-age peut afficher null parce que npm le convertit en interne à une marque temporelle before, et vous ne pouvez pas le combiner avec --before. Pour installer rapidement un correctif critique, override par commande avec --min-release-age=0.

4. Inspecter le manifeste sans installer

Regardez ce que le paquet déclare avant de toucher votre système :

npm view some-tunnel-cli@1.2.3 scripts bin dependencies --json
npm pack some-tunnel-cli@1.2.3   # télécharge uniquement le tarball
tar -tzf some-tunnel-cli-1.2.3.tgz

Les signaux d’alerte : tout preinstall/install/postinstall qu’un CLI pur n’a aucune raison d’utiliser, une entrée bin pointant vers un fichier d’installation ou de chargement au lieu du point d’entrée réel, et des dépendances nouvellement ajoutées. Les deux signaux sont apparus dans le manifeste Bitwarden.

5. Vérifier dans un répertoire éphémère, puis vérifier les attestations

npm audit signatures vérifie les signatures du registre et les attestations de provenance, mais il opère sur les dépendances installées dans un projet, il ne vérifie pas directement une installation globale. Installez dans un répertoire scratch avec les scripts désactivés, puis auditez :

mkdir /tmp/vet  cd /tmp/vet  npm init -y
npm install --ignore-scripts some-tunnel-cli@1.2.3
npm audit signatures

La documentation de npm exige npm 9.5.0 ou plus récent pour cela. Puis lisez l’attestation elle-même. Le registre expose les attestations à registry.npmjs.org/-/npm/v1/attestations/<package>@<version>. Confirmez que le dépôt source et le workflow correspondent au dépôt officiel du fournisseur, et que la version comporte une attestation, même si des versions antérieures en avaient.

6. Décider quels scripts peuvent être exécutés

Sur npm 12, n’approuvez que ce que vous comprenez. Pour un outil global qui nécessite réellement un postinstall :

npm install -g --allow-scripts=some-tunnel-cli some-tunnel-cli@1.2.3

7. Si le seul script du paquet est un téléchargeur binaire, c’est le signal pour la prochaine section.

Préférer des binaires autonomes vérifiés par somme de contrôle

De nombreux clients tunnel se diffusent sous forme de binaires statiques uniques. Installer directement le binaire supprime l’arbre de dépendances npm, le téléchargement postinstall de l’enveloppe et la surface d’attaque à l’importation en une seule étape.

Cloudflare publie des sommes de contrôle SHA-256 pour chaque actif cloudflared dans ses notes de version GitHub. Une installation pinée et vérifiée ressemble à ceci :

VERSION=<reviewed-release-tag>
curl -fsSLO "https://github.com/cloudflare/cloudflared/releases/download/${VERSION}/cloudflared-linux-amd64"
echo "<sha256-you-recorded-at-review-time>  cloudflared-linux-amd64" | sha256sum -c -
install -m 0755 cloudflared-linux-amd64 /usr/local/bin/cloudflared

Soyez honnête sur ce que cela prouve. Une somme de contrôle copiée depuis la même page de release que le binaire protège contre la corruption et les chemins de téléchargement compromis, pas une release compromise. Enregistrez le hash dans votre propre dépôt ou dans votre code d’infrastructure lorsque quelqu’un revoit la release, et faites que votre script de provisioning le compare.

Lorsque un projet publie des attestations d’artéfacts GitHub, ajoutez gh attestation verify ./some-binary --repo owner/repo. L’outil gh doit être authentifié même pour les dépôts publics, et certains installateurs ignorent la vérification lorsque une release n’a pas d’attestation (la documentation Foundry indique que son installateur le fait), alors faites échouer votre propre script. Ces attestations partagent la limite de la provenance npm : elles identifient la construction, pas l’intention de l’auteur.

Verrouiller les sorties

Un client tunnel a besoin de très peu d’accès sortant. La plupart des charges malveillantes nécessitent davantage : quelque part pour envoyer des fichiers volés et parfois pour récupérer une seconde étape. Le chargeur Bitwarden a téléchargé le runtime Bun depuis GitHub, et son point de fuite était conçu pour ressembler au domaine de télémétrie d’un fournisseur de sécurité.

Exigences documentées pour deux clients populaires :

• cloudflared se connecte en sortant sur le port 7844, TCP pour HTTP/2 ou UDP pour QUIC, et ouvre quatre connexions sortantes vers au moins deux centres de données Cloudflare. Le guide firewall de Cloudflare liste region1.v2.argotunnel.com et region2.v2.argotunnel.com, ajoute des noms d’hôtes tels que cftunnel.com pour les firewalls à SNI et considère les destinations sur le port 443 comme optionnelles (pour les mises à jour). Il recommande de bloquer tout ingress.
• ngrok agents établissent une connexion TLS sortante sur le port 443 vers connect.ngrok-agent.com. La documentation de ngrok indique que ses adresses IP tournent et doivent être autorisées par nom d’hôte, et que la famille *.ngrok-agent.com peut être nécessaire en raison du routage basé sur la latence. Vous pouvez aussi white-labeler l’URL de connexion et exécuter ngrok diagnose pour tester la connectivité.

Puisque les destinations sont des noms d’hôtes, les règles basées sur des IP simples ne suffisent pas. Utilisez un pare-feu conscient du FQDN, un proxy ou une politique style Cilium toFQDNs, et appliquez-la à l’utilisateur ou au conteneur qui exécute le tunnel, pas seulement à tout l’hôte.

Une liste d’autorisation réduit l’étendue des dégâts mais ne l’efface pas : les points de terminaison du fournisseur du tunnel restent nécessairement autorisés.

Exécutez-le comme s’il pouvait être compromis

Supposez que le client puisse un jour être la mauvaise release que vous n’avez pas repérée. Exécutez-le en tant qu’utilisateur dédié ou dans un conteneur sans identifiants cloud, clés SSH ou tokens de publication en accès, démarrez-le dans un environnement propre plutôt que dans un shell chargé de secrets exportés, et utilisez un jeton d’authentification à périmètre étroit que vous pouvez faire tourner. N’exposez que le seul port dont vous avez besoin.

Tout ce qui précède porte sur la confiance envers le client. Détecter des tunnels que vous n’avez pas autorisés est un problème distinct, abordé dans notre post précédent sur la détection des tunnels SSH inverses frauduleux.

FAQ

Est-ce que npm 12 rend npm install -g sûr ? Non. Il bloque par défaut les scripts d’installation des dépendances, ce qui retire une des grandes voies d’attaque. Le code qui s’exécute lorsque vous importez un module ou invoquez le CLI reste inchangé.

La provenance npm suffit-elle pour faire confiance à un paquet ? Non. La provenance indique où et comment un paquet a été construit. Plusieurs incidents en 2026 ont diffusé des versions malveillantes via des pipelines légitimes avec des attestations valides, il faut donc vérifier que l’attestation correspond au dépôt attendu et la combiner avec le pinning des versions et l’examen des manifestes.

La conclusion

npm 12 a relevé le niveau et les attaquants ont migré vers des endroits non couverts. Considérez la provenance comme un indice parmi d’autres sur l’origine d’une release, pas comme une réponse sur le fait de savoir s’il faut l’exécuter. Pour un client Tunnel longue durée, authentifié et exposé au réseau : verrouillez une version examinée, laissez passer les jours initiaux d’une release, privilégiez des binaires vérifiés par hash, et laissez le processus n’atteindre que les hôtes dont il a besoin.

Sources

• npm 12 Disables Install Scripts by Default to Reduce Supply Chain Risk, The Hacker News (Jul 2026)
• Upcoming breaking changes for npm v12, GitHub Changelog (Jun 9, 2026)
• npm CLI PR #9424: block unreviewed install scripts by default (v12)
• npm CLI issue #9797: global install allow-scripts warning
• npm approve-scripts vs allow-scripts, DEV Community
• Unpacking the AsyncAPI npm supply chain compromise and import-time payload delivery, Microsoft Security Blog
• AsyncAPI npm Attack: Import-Time Malware Defense Guide, Digital Applied
• TeamPCP Campaign Spreads to npm via a Hijacked Bitwarden CLI, JFrog
• Bitwarden CLI Impersonation Attack, Palo Alto Networks
• A Simple Defense Against npm Supply Chain Attacks, OpenReplay
• The npm Threat Landscape: Attack Surface and Mitigations, Unit 42
• Why npm Provenance Didn’t Stop the TanStack Compromise, AppSec Santa
• Attackers Abuse npm Trusted Publishing in GHAPPIER Campaign, Infosecurity Magazine
• npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover, Help Net Security
• Your node_modules Is an Attack Surface: npm Security Checklist for 2026, DEV Community
• npm Supply Chain Security in 2026, Mondoo
• Generating provenance statements, npm Docs
• Viewing package provenance, npm Docs
• npm audit, npm Docs
• Configuring minimum release age across npm, pnpm, and yarn (gist)
• ngrok Node.js wrapper README
• cloudflared releases, GitHub
• Tunnel with firewall, Cloudflare Docs
• Cloudflare Tunnel configuration, Cloudflare Docs
• ngrok network egress, ngrok Docs
• ngrok custom connect URL, ngrok Docs
• Use artifact attestations, GitHub Docs
• Verifying releases, Foundry docs
• Integrity verification, Qlty docs