NPM sous attaque : le ver qui vole les justificatifs et vérifie vos pipelines CI

Le 4 août 2026, une campagne d'empoisonnement de npm a été détectée qui a commencé avec la version malveillante keyv @ 6.0.0 et rapidement élargie par plusieurs noms de paquets et organisations. C'était un ver conçu pour voler des références., qui a été activé par un script de pré-installation et a déployé un binaire emballé capable d'exfilter des jetons et clés de dépôt, des enregistrements, des nuages et des coureurs d'intégration continue (CI), ainsi que des mécanismes pour publier de nouvelles versions avec des identités volées.

La télémétrie des chercheurs indépendants n'était pas d'accord sur un seul décompte final : SafeDep a vérifié des centaines de versions malveillantes dans des dizaines de paquets, Aikido a présenté un décompte encore plus grand et d'autres observations enregistrées des points partiels. Le nombre total de paquets ou de versions déclarés indique l'échelle, mais ne correspond pas au nombre de systèmes de victimes; une telle détermination nécessite de vérifier la version exacte résolue sur chaque machine et, surtout, si le script du cycle de vie a été exécuté.

Du point de vue technique, la campagne a utilisé un fichier pré-install qui a invoqué setup.mjs et a déployé un paquet compilé qui cherchait des runtimes comme Bun, des composants téléchargés puis exécuté un code qui a exploré la mémoire du coureur, lu des secrets dans des fichiers et des variables d'environnement, et placé un "watcher" dont la fonction était d'observer les retorations de jetons. Ce moniteur pose un risque opérationnel important: d'abord, la rotation des références peut tirer un contrôleur local fourni par l'attaquant, donc les équipes de réponse devraient neutraliser le malware avant de commencer la rotation.

La surface d'attaque était plus grande parce que le dépôt compromis contenait également des crochets pour les éditeurs et les environnements de développement: Claude Code et Visual Studio Code fichiers de configuration qui, s'ils sont fiables, peuvent exécuter setup.mjs lors de l'ouverture du projet. Dans les environnements de développement et dans les coureurs CI il y a deux vecteurs indépendants - l'installateur npm et la configuration de l'espace de travail - et les deux doivent être considérés comme potentiellement dangereux.

La campagne a révélé que les garanties de provenance et de signature de construction ne sont pas une panacée: plusieurs des rejets empoisonnés portaient des signatures valides et des postes SLSA parce que le flux de publication passait par le pipeline légitime du projet. Une attestation qui vérifie le processus de construction ne garantit pas à elle seule que le code source qui a entré ce processus est sûr, et par conséquent la vérification de la chaîne d'approvisionnement devrait inclure des contrôles sur le dépôt source et sur qui contrôlait les pouvoirs de publication.

Pour détecter l'exposition dans votre environnement, il est essentiel d'utiliser les sources locales : inspect package-lock.json, npm-shrinkwrap.json, fil. Verrouillage et pnpm-lock. yaml pour localiser les versions exactes résolues; vérifier si le manifeste contenait un script pré-install ou des fichiers suspects (par exemple setup.mjs ou des noms inhabituels inclus dans la publication); et analyser les journaux de CI et d'installation pour voir si les scripts du cycle de vie ont été exécutés. Ne vous fiez pas aux listes publiques de paquets "derniers" ou aux blocs de noms d'espace; la vérification doit être faite par le nom exact et la version..

La réponse technique immédiate devrait combiner l'isolement et l'élimination des malwares avec un plan de rotation coordonné des références. Tout d'abord, les machines et les coureurs suspects de quarantaine et fouillent et retirent le surveillant ou tout dispositif persistant qui peut réagir à la révocation. Puis, les clés rotées, les jetons et les certificats commis. Si elle est cassée sans neutraliser d'abord l'observateur, il y a un risque d'activer le code de l'attaquant qui profite de la rotation. Enfin, reconstruire les artefacts et les contenants à partir de sources fiables et d'arbres de code vérifiés.

Dans l'infrastructure CI / CD et les politiques de développement, il existe des mesures concrètes pour réduire l'exposition future : mettre à jour les clients npm qui bloquent les scripts de cycle de vie par défaut lorsqu'ils sont compatibles avec leur flux, désactiver l'exécution automatique des tâches d'espace de travail dans VS Code et Claude Code, adopter des jetons éphémères et OIDC pour les déploiements, restreindre les autorisations de publication dans les enregistrements et exiger l'authentification multifactorielle et des examens humains pour les versions critiques. Une sécurité efficace combine des outils (par exemple, verrouillage des scripts du cycle de vie), des politiques (principe de privilège minimal) et des processus (examen des engagements et contrôle de l'accès aux références).

Les équipes de maintenance de l'emballage doivent vérifier leur arbre de travail et l'historique des engagements à la recherche de changements qui ont répandu des fichiers suspects à plusieurs sous-emballages. Faites attention aux engagements signés ou vérifiés par des robots qui, même s'ils présentent un badge de vérification, n'identifient pas qui contrôlait le titre qui a signé l'action. La vérification de la signature est nécessaire, mais elle n'est pas suffisante; combiner ce signal avec des contrôles sur les personnes ayant accès au pipeline et des révisions de l'intégrité du code source.

Pour les consommateurs et les organisations, la recommandation pratique immédiate est d'identifier les cas spécifiques qui pourraient installer les versions touchées et de déterminer si les scripts d'installation ont été exécutés. Si vous confirmez l'exécution, isolez la machine et le coureur, conservez les preuves et passez au nettoyage et à la rotation des secrets conformément à l'ordre décrit. Si vous n'êtes pas sûr de l'état de l'exécution, traitez les machines comme potentiellement exposées pour prouver le contraire avec des images ou reconstruisent à partir de sources propres.

Pour approfondir les pratiques de vérification de la signature et le cadre recommandé de l'ASL pour les attentions de la chaîne d'approvisionnement, voir la documentation officielle de GitHub sur la vérification de la signature A propos de la vérification de la signature du commit et les principes du projet SLSA Slsa.dev. Pour l'analyse de campagne et les engagements de dépôt, des ressources telles que le blog Semgrep collectent des exemples utiles et des règles qui peuvent être appliqués dans les analyses de dépôt; consultez votre page de publications à Semgrep Blog.

Cet incident met en lumière une leçon clé : les défenses de la chaîne d'approvisionnement doivent être proactives, centrées sur la précision (versions résolues et fichiers de verrouillage) et sur l'hygiène des références. Les organisations devraient revoir leurs processus de publication, resserrer les pipelines, limiter le rayon d'explosion des jetons et préparer des cahiers d'intervention qui envisagent la rotation ordonnée de la campagne secrète après l'élimination de tout mécanisme de surveillance installé par l'agresseur.