Une nouvelle vague de compromission de la chaîne d’approvisionnement logicielle a été observée début août 2026 : le Keyv worm npm a été identifié autour de la version keyv@6.0.0, puis propagé à de nombreuses publications dans le registre npm. Des analyses de plusieurs équipes décrivent un mécanisme basé sur des scripts de vie (notamment préinstall) capables de viser des environnements de développement et d’intégration continue (CI).
Le point marquant n’est pas seulement l’ampleur du nombre de versions contaminées, mais aussi la manière dont le code peut s’exécuter côté poste de travail (via des hooks d’outils) et côté pipeline (via des scripts d’installation). Voici ce que l’on sait, ce qui reste incertain, et comment réduire le risque.
Comment le Keyv worm npm s’est propagé
Selon les vérifications réalisées, la compromission a débuté avec keyv@6.0.0. À partir de là, des versions malveillantes se sont retrouvées au-delà des espaces de noms directement liés à Keyv, jusqu’à toucher des centaines de paquets répartis entre plusieurs organisations.
Les chiffres exacts divergent selon les méthodologies : SafeDep a identifié un ensemble de versions empoisonnées à partir d’une liste de vérification, tandis qu’Aikido a donné une estimation plus large. Les auteurs des rapports précisent toutefois que l’on ne peut pas reconstruire l’étendue totale de manière indépendante via une liste publique exhaustive au moment de la coupure des signalements.
Le mécanisme d’attaque : scripts préinstall et collecte de secrets
Le Keyv worm npm exploite un comportement courant : lors de l’installation d’un paquet, certains scripts peuvent s’exécuter automatiquement. Dans les versions concernées, un script de préinstall lance un ensemble de charge utile (payload) orienté vol d’informations.
D’après les analyses, le payload peut chercher et extraire des données sensibles, notamment :
- les identifiants et secrets liés au dépôt et au registre de paquets npm ;
- des éléments de configuration cloud ;
- des matières privées comme des clés privées ;
- des informations provenant de services associés à des environnements de production (selon la configuration et la présence des composants).
Le rapport indique aussi que la charge peut intégrer des composants destinés à publier davantage de paquets en abusant d’un accès légitime au registre, ce qui aide à expliquer la propagation.
Exécution dans CI et en environnement de développement
Le risque ne se limite pas aux machines de développeurs. Comme le Keyv worm npm est déclenché via un chemin d’installation (et donc via la résolution de dépendances), des systèmes d’intégration continue peuvent exécuter la charge lorsqu’ils récupèrent et installent des dépendances.
Les analyses recommandent de considérer comme potentiellement exposés les workstations ou runners qui ont exécuté une version affectée. Le simple fait d’avoir effectué une installation peut donc être un signal d’alerte, même si l’on ne dispose pas, pour toutes les victimes, d’une preuve d’exécution effective.
Deux voies d’exécution : hooks d’outils et scripts d’installation
Un aspect particulièrement préoccupant concerne les mécanismes d’exécution “cachés” dans des configurations d’outils d’édition. Les rapports mentionnent que le dépôt associé conserve des hooks pour deux environnements : un flux pouvant déclencher du code après la confiance accordée à un espace de travail, et un autre dépendant du déclenchement de tâches lors de l’ouverture d’un dossier.
Dans le détail, des fichiers de configuration (notamment des paramètres de session et des tâches définies dans des répertoires de configuration de l’éditeur) peuvent appeler un script, ce qui crée une “route” d’exécution lorsque certaines conditions sont réunies (confiance de l’espace de travail, autorisation des tâches, etc.).
Les mêmes rapports précisent toutefois que ces fichiers ne s’exécutent pas automatiquement dans tous les contextes par défaut : selon les politiques de l’éditeur, des invites ou des blocages peuvent empêcher l’exécution non approuvée.
Pourquoi certaines versions sont bloquées et d’autres restent exposées
Un autre point clé concerne l’évolution des comportements de l’outil de gestion des dépendances. Le rapport indique que npm 12 bloque par défaut certains scripts de dépendance non approuvés via les scripts de cycle de vie. En revanche, les clients npm plus anciens ou d’autres chemins d’installation pouvant autoriser l’exécution de scripts restent potentiellement vulnérables.
Autrement dit : mettre à jour npm peut réduire l’exposition, mais ne suffit pas à lui seul, car le risque dépend aussi de la façon dont les dépendances sont installées, de l’environnement et du moment exact où les versions ont été résolues.
Ce qui a été observé dans la version keyv@6.0.0
Les premiers éléments confirmés concernent keyv@6.0.0. Les observateurs indiquent que cette version ajoute un fichier node setup.mjs comme commande de préinstall. Le paquet inclut également des fichiers auxiliaires (notamment setup.mjs et un autre module) tout en laissant le code compilé de la bibliothèque à un niveau inchangé.
Le déroulé décrit pour la phase suivante comporte une détection d’un runtime alternatif : la charge vérifie la présence de Bun, et si nécessaire télécharge une version depuis une source officielle du runtime. Ensuite, elle passe à une charge compilée de grande taille.
Le rapport précise que l’analyse du payload identifie des capacités étendues : collecte d’informations issues d’écosystèmes comme GitHub, npm et plusieurs environnements cloud, mais aussi lecture de mémoire de certains runners d’automatisation, installation d’un mécanisme de “watcher” lié à la révocation de jetons, et intégration de pièces nécessaires à des actions de publication npm.
Propagation et “latest” : pourquoi la liste exacte n’est pas fiable
Les signaux de compromission ont été compliqués à suivre en raison de la rapidité des changements dans le registre. Les pages de paquets peuvent afficher à un instant donné une version listée comme latest, même si auparavant une version malveillante a été marquée de la sorte, puis remplacée, ou inversement.
Les analyses indiquent qu’à un moment précis, plusieurs paquets avaient vu des versions antérieures réapparaître comme “latest” après restauration. Parmi les exemples cités figurent keyv@5.6.0, flat-cache@6.1.23 et cache-manager@7.2.9.
La conséquence pour la défense est claire : se fier aux tags actuels ou à une liste mise en cache peut conduire à des erreurs. Les équipes recommandent de vérifier à partir des noms de paquets, des versions résolues et des lockfiles utilisés réellement sur vos systèmes.
Révocation des tokens : l’ordre des actions compte
Les rapports soulignent un risque opérationnel : le malware installe un mécanisme qui attend un événement lié à la révocation des identifiants. Si l’on révoque des jetons avant d’avoir retiré ou neutralisé le composant surveillé, il est possible qu’un gestionnaire local fourni par l’attaquant s’exécute dans la foulée.
En pratique, une recommandation formulée est d’abord retirer le watcher lié au mécanisme de révocation, puis seulement ensuite procéder à la rotation des jetons et des clés exposés. Ce point illustre pourquoi l’intervention doit être structurée : “révoquer d’abord” n’est pas nécessairement le meilleur scénario.
Ce qui est prouvé, et ce qui reste incertain
Les rapports établissent que les artefacts publiés ont pu passer par un flux légitime : la version malveillante décrite porte des éléments de provenance (attestations) et a suivi le processus standard de publication via une chaîne d’actions. Cependant, les mêmes analyses indiquent que la provenance ne prouve pas, à elle seule, que la source ayant alimenté le processus était saine.
Autre limite : le Keyv worm npm ne révèle pas automatiquement si la propagation vient d’un seul identifiant de publication compromis ou de plusieurs accès séparés. Les observations sur la “rafale” de paquets ne permettent pas, à partir des données disponibles, d’attribuer de façon certaine le nombre d’identités atteintes.
Enfin, il n’y a pas de signalement public côté mainteneurs, npm ou GitHub repéré au moment des rapports consultés. Cela signifie que les défenses doivent s’appuyer sur des analyses techniques et des contrôles internes (audit de dépendances, recherche de versions résolues).
Pourquoi vérifier au niveau du projet, pas seulement au niveau du namespace
Un blocage par namespace (ou par liste “globale” de paquets) peut être tentant, mais risqué. Les rapports indiquent que certains paquets “liés” au mainteneur n’étaient pas nécessairement empoisonnés. De plus, des commit ultérieurs peuvent réorganiser des fichiers de charge utile dans un dépôt de travail, de sorte que des sorties ultérieures puissent intégrer des éléments malveillants même si tout n’est pas contaminé de manière identique.
Pour cette raison, la stratégie la plus sûre consiste à :
- identifier les dépendances réellement installées via les lockfiles ;
- contrôler les versions résolues, et pas uniquement les versions “visibles” aujourd’hui ;
- chercher les chemins d’exécution (scripts de préinstall, hooks d’outils, tâches déclenchées à l’ouverture de dossier selon la confiance).
Que faire maintenant : une checklist de réduction de risque
Si vous utilisez des paquets potentiellement touchés, l’objectif est de limiter l’impact sans créer de nouveaux risques opérationnels. Les recommandations ci-dessous s’inspirent directement des constats décrits dans les analyses.
- Audit : examinez les lockfiles et l’arbre de dépendances pour repérer toute résolution vers des versions affectées.
- Surveillance : traquez les environnements CI et les machines de build qui ont installé les versions concernées.
- Neutralisation : avant de faire la rotation massive, supprimez les mécanismes de révocation/observateurs décrits comme installés par la charge utile (l’approche exacte dépend de votre contexte).
- Rotation : remplacez les jetons et clés réellement exposés, après neutralisation, en documentant l’ordre des opérations.
- Mise à niveau : lorsque c’est possible, utilisez des versions d’outils qui réduisent l’exécution de scripts de cycle de vie non approuvés.
Cette démarche aide à transformer un incident “chaîne d’approvisionnement” en programme de correction vérifiable, au lieu de suppositions basées sur l’état du registre au moment du contrôle.
Conclusion
Le Keyv worm npm montre une fois de plus comment des attaques de supply chain peuvent combiner plusieurs déclencheurs : scripts d’installation et hooks liés à des outils de développement, avec un objectif central de vol de secrets et d’extension de la portée via des capacités de publication. Les estimations de l’ampleur diffèrent, mais le message opérationnel reste identique : vérifiez les versions résolues dans vos projets, traquez l’exécution côté CI et appliquez une séquence d’intervention prudente autour de la révocation des identifiants.
Si vous le souhaitez, je peux aussi proposer un modèle de procédure interne (audit + rotation + preuves) adapté à votre environnement CI/CD et à votre façon de gérer les lockfiles.
Source: https://thehackernews.com/2026/08/keyv-linked-npm-worm-poisons-hundreds.html
