La provenance npm n'est pas un gage de sûreté : le ver tensorlake

Le badge vert de provenance sur un paquet npm vous dit où le paquet a été construit. Il ne vous dit pas que le code est sûr. D'après le tracker d'incidents pwn.watch, tensorlake@0.5.144 a été publié le 8 octobre 2026 depuis le vrai dépôt GitHub du projet, avec la provenance npm, et embarquait un hook preinstall qui installe un ver voleur d'identifiants du type Shai-Hulud. Si votre équipe traite la provenance comme un signal de confiance, c'est le cas à lire, parce que le badge était authentique.

Ce que rapporte le tracker

Tout ce qui suit dans cette section est le résumé du tracker, le récit d'un seul agrégateur ; c'est l'avis du paquet lui-même qu'il faut vérifier avant d'agir. Le tracker classe l'entrée comme partiellement corrigée. Il indique que le hook récolte les secrets npm, GitHub, cloud, SSH et d'outils d'IA, se propage à d'autres paquets, et installe un watcher nommé "gh-token-monitor" qui efface le répertoire personnel si le token GitHub volé est révoqué. Son conseil : épingler 0.5.143, et supprimer ce watcher avant de faire tourner les tokens. Ce dernier point inverse le réflexe habituel de révoquer d'abord, et c'est pour ça qu'il compte.

Ce que la provenance prouve, et ce qu'elle ne prouve pas

Ceci relève de la culture générale sur le fonctionnement de la provenance. La provenance est une déclaration signée selon laquelle un dépôt et un workflow donnés ont produit le paquet. Elle ferme bien une brèche : quelqu'un qui publie une imitation depuis un portable avec un token volé ne peut pas la falsifier. Elle ne dit rien sur le caractère inoffensif du code de ce dépôt à ce moment-là. Si un attaquant entre dans le pipeline de build ou dans le compte d'un mainteneur, la version malveillante est construite depuis le vrai dépôt et porte une vraie provenance.

GitHub resserre le côté publication. Son changelog indique que les configurations de trusted publishing npm non validées expirent désormais au bout de 48 heures, que les tokens de trusted publishing issus d'événements issue_comment sont refusés, et que npm stage publish exige qu'un mainteneur promeuve la première version d'un nouveau paquet. GitHub note aussi que les malwares agissent de plus en plus à l'installation, en récoltant des identifiants sur les hôtes de CI et les postes de travail sans que votre app n'exécute jamais le code du paquet. C'est exactement la forme de cet incident, et c'est pourquoi la défense doit se placer à l'installation.

Le chemin de npm install jusqu'à vos secrets

Culture générale, encore : les scripts preinstall et install s'exécutent pendant npm install avec les droits de votre utilisateur, donc tout ce que votre shell peut lire, le script peut le lire. Sur un portable, ce sont vos clés SSH et votre config cloud. Sur un runner de CI, c'est chaque secret injecté dans le job.

Coupure 1, choisir ce qui s'installe. Commitez le lockfile et installez à partir de lui, pour qu'une nouvelle version n'arrive que quand vous le décidez. Un délai d'attente, c'est-à-dire ne pas adopter de version âgée de moins de quelques jours, fait gagner du temps, car les versions malveillantes sont souvent repérées en quelques jours. Le pare-feu de paquets de GitHub, en préversion publique pour Enterprise Cloud et npm uniquement, propose un délai configurable de ce genre. Coupure 2, ne pas exécuter les scripts d'installation par défaut. npm ci --ignore-scripts les saute ; certains paquets ont vraiment besoin des leurs, alors autorisez ceux-là délibérément. Coupure 3, tenir les secrets à l'écart de l'étape d'installation. Un job de CI qui installe des dépendances n'a pas besoin de vos clés de déploiement dans son environnement.

npm ci --ignore-scripts
npm ls tensorlake

Si tensorlake 0.5.144 a tourné sur une machine

L'ordre général : isoler la machine ou le runner, établir ce qui a tourné, puis faire tourner chaque secret qu'il pouvait lire, depuis une machine propre. Dans ce cas précis, selon le tracker, cherchez et supprimez le watcher de token avant de révoquer le token GitHub. Vérifiez chaque étape avec l'avis du paquet lui-même, pas seulement avec ce résumé.

Source : le tracker d'incidents pwn.watch, entrée "tensorlake@0.5.144 npm Shai-Hulud worm with hostage GitHub token".