Keyv npm Worm : 420 paquets empoisonnés en 30 minutes

Un ver npm se propage à 420 paquets en trente minutes

Le 4 août 2026, la communauté open source a subi l'une des attaques de chaîne d'approvisionnement npm les plus rapides et les plus destructrices jamais documentées. Un ver malveillant, rapidement baptisé "Shai-Hulud" par les chercheurs de SafeDep — en référence au ver des sables géant de l'univers Dune, symbole d'une force imprévisible et dévastatrice — a été injecté dans [email protected], la nouvelle version majeure de keyv. Cette librairie de stockage clé-valeur, prisée pour son abstraction universelle des backends de cache (Redis, SQLite, PostgreSQL, MongoDB, Memcache), cumule environ 127 millions de téléchargements hebdomadaires sur le registre npm, en faisant l'un des paquets les plus téléchargés de l'écosystème Node.js.

L'attaque a débuté par la compromission du compte GitHub du mainteneur principal de keyv, identifié sous le pseudonyme "Jaredwray", qui contrôlait à la fois les namespaces npm keyv et cacheable. Les attaquants ont exploité cet accès pour publier directement sur npm des versions malveillantes, contournant toute revue de code. La malveillance était inscrite dès le dépôt GitHub : les chercheurs de JFrog Research ont relevé que les dépôts concernés portaient la description "Shai-Hulud: Here We Go Again", marqueur délibéré d'une campagne déjà observée antérieurement sous une forme moins sophistiquée.

Le mécanisme de propagation est ce qui distingue fondamentalement cette attaque des compromissions de paquets classiques : il s'agit d'un véritable ver, pas simplement d'un paquet malveillant statique. Selon les analyses publiées par SafeDep et Socket le jour même, le code malveillant — une fois exécuté dans un environnement de développement ou un pipeline CI/CD — exploitait automatiquement les jetons npm disponibles dans l'environnement pour republier des versions infectées d'autres paquets contrôlés par la même organisation. La vitesse de propagation documentée est stupéfiante : le ver progressait d'une organisation à la suivante en deux à sept minutes seulement. En trente minutes, neuf organisations distinctes et indépendantes avaient été touchées : les namespaces @ornikar, @deliveroo, @onereach, @or-sdk, @arv-bedrock, @servicetitan, @qlik, @adminide-stack, ainsi que la famille keyv et cacheable elle-même.

Sur le plan technique, le vecteur d'infection reposait sur un hook preinstall malveillant injecté dans le champ scripts du package.json des paquets compromis. Ce script, exécuté automatiquement lors de chaque npm install, chargeait un loader nommé setup.mjs conçu pour le runtime JavaScript Bun. Ce choix du runtime Bun — moins surveillé que Node.js dans les environnements CI/CD — est une innovation tactique notable. Le loader déclenchait ensuite un bundle obfusqué chargé de récolter des credentials dans l'environnement d'exécution. D'après les analyses de Snyk et Aikido Security, la liste des secrets ciblés est particulièrement exhaustive : jetons GitHub et secrets GitHub Actions (extraits directement depuis la mémoire du runner CI/CD), clés d'API npm, clés d'accès AWS, GCP et Azure, chaînes de connexion aux bases de données, clés privées SSH et GPG, tokens Stripe, secrets HashiCorp Vault et configurations Kubernetes.

La caractéristique la plus préoccupante de cette campagne, documentée par The Hacker News et Wiz Research, réside dans le mécanisme de persistance par hooks IDE. Au-delà de l'exfiltration de secrets pendant l'installation, le ver modifiait deux fichiers de configuration dans les projets contaminés : .claude/settings.json (en y ajoutant un hook SessionStart) et .vscode/tasks.json (en y injectant une tâche folderOpen). Ces hooks étaient cross-wired — ni le répertoire .claude ni le répertoire .vscode ne semblait auto-contenu — et s'exécutaient automatiquement la prochaine fois qu'un développeur ouvrait le dépôt dans Visual Studio Code ou démarrait une session Claude Code, sans qu'aucun npm install supplémentaire ne soit nécessaire. La persistance survit donc à la suppression du paquet malveillant.

SafeDep a procédé à une énumération exhaustive de l'étendue de la contamination sur le registre npm : 1 684 versions empoisonnées réparties sur 420 noms de paquets différents. L'analyse de Wiz qualifie la charge utile de descendant de la famille de malware "Mini" Shai-Hulud, tandis que JFrog Research confirme une évolution directe de la même famille, avec des capacités élargies. Des recherches ultérieures de FalconFeeds pointent également une extension de la menace au-delà de l'écosystème npm vers PyPI, suggérant que les acteurs testent la portabilité de leur ver à d'autres registres de paquets.

Sur le front de la remédiation, le registre npm a procédé à la suppression des 1 684 versions compromises dans les heures suivant la détection. GitHub a révoqué les accès du compte compromis du mainteneur. Les organisations touchées ont été notifiées par les équipes de sécurité de npm et GitHub. Des versions saines des paquets keyv et cacheable ont été republiées après audit complet. Toutefois, la fenêtre d'exposition — de la publication initiale de la version malveillante jusqu'aux premières suppressions — couvre plusieurs heures pendant lesquelles des milliers de pipelines CI/CD dans le monde ont pu exécuter le paquet infecté dans le cadre de leurs builds normaux.

Pour les organisations utilisant des paquets de la famille keyv ou cacheable dans leurs projets Node.js, l'urgence est double : vérifier si les versions affectées ont été exécutées dans leurs environnements, et auditer leurs configurations IDE pour détecter d'éventuels hooks persistants dans .claude/settings.json et .vscode/tasks.json. La liste complète des 420 paquets compromis est disponible dans les rapports publiés par SafeDep, Socket et Wiz Research.

Pourquoi cette attaque change la menace supply chain

Cet incident marque une évolution qualitative majeure dans les attaques de chaîne d'approvisionnement npm. Jusqu'à présent, la plupart des compromissions de paquets consistaient en des injections statiques — un paquet malveillant était publié et attendait passivement d'être installé. L'aspect auto-propagateur de Shai-Hulud, qui exploite les jetons npm disponibles dans les environnements infectés pour contaminer d'autres paquets de la même organisation, introduit une dynamique de ver qui multiplie exponentiellement l'impact d'un point d'accès initial unique. Neuf organisations indépendantes touchées en trente minutes à partir d'un seul compte compromis illustre concrètement ce potentiel multiplicateur.

La persistance par hooks IDE représente une évolution particulièrement inquiétante. Les équipes de sécurité qui détectent rapidement une compromission et révoquent leurs secrets doivent maintenant également vérifier les fichiers de configuration de leurs outils de développement — Claude Code, VS Code, et potentiellement d'autres IDEs. Cette surface de persistance, relativement nouvelle, n'est pas encore couverte par la majorité des politiques de réponse à incident. La capacité à survivre à la désinstallation du paquet malveillant transforme une compromission ponctuelle en une infection persistante difficile à éradiquer sans une procédure de nettoyage explicitement dédiée aux configurations IDE.

Sur un plan sectoriel plus large, cet incident s'inscrit dans une série inquiétante de compromissions ciblant l'écosystème npm. Après les campagnes Sapphire Sleet via des paquets axios malveillants, les 18 paquets RAT ciblant les développeurs Alibaba, et maintenant Shai-Hulud sur keyv, il est évident que les registres de paquets open source sont devenus des cibles prioritaires pour des acteurs de menace sophistiqués. La combinaison d'un accès immédiat à des millions d'environnements de développement, d'une exécution de code avant toute interaction utilisateur (via les scripts preinstall), et d'une confiance implicite des développeurs envers les paquets populaires crée un vecteur d'attaque d'une efficacité redoutable.

Pour les responsables de la sécurité, les enseignements pratiques sont multiples. La gouvernance des jetons npm au sein des organisations doit être revue : les pipelines CI/CD ne devraient disposer que des permissions minimales nécessaires à la publication de leurs propres paquets, jamais de tokens multi-namespace capables de publier au nom de toute l'organisation. L'adoption de mécanismes de vérification d'intégrité (signatures de paquets via npm provenance, vérification de hachages) et d'une politique de mise en quarantaine des nouvelles versions de paquets tiers avant leur déploiement en production constitue la réponse adaptée à cette classe de menace. Enfin, l'intégration de la détection de scripts preinstall malveillants dans les pipelines DevSecOps — via des outils comme Socket, Snyk ou Aikido — devient une nécessité opérationnelle.

Ce qu'il faut retenir

• Vérifiez immédiatement vos dépendances sur keyv, cacheable et leurs dérivés — consultez les rapports de SafeDep et Socket pour la liste des 420 paquets compromis et auditez vos logs npm install du 4 août.
• Révoquez et effectuez une rotation de tous les secrets potentiellement exposés dans vos environnements CI/CD : tokens GitHub, clés AWS/GCP/Azure, tokens npm, secrets Kubernetes — même sans confirmation de compromission.
• Auditez les fichiers .claude/settings.json et .vscode/tasks.json dans vos dépôts : le ver y plante des hooks persistants qui survivent à la suppression du paquet et s'exécutent à l'ouverture de l'IDE.