Ver npm keyv : 444 paquets compromis en supply chain

Comment un seul compte GitHub a intoxiqué un milliard de dépendances JavaScript

Le 4 août 2026, les équipes de SafeDep, Aikido Security, Snyk, Wiz et Datadog Security Labs ont déclenché leurs alertes dans un intervalle de quelques heures : un ver de type supply chain venait de s'introduire au cœur de l'un des sous-systèmes de cache les plus utilisés de l'écosystème Node.js. En moins de vingt-quatre heures, 2 234 versions malveillantes étaient publiées sur le registre npm, couvrant 444 noms de paquets distincts selon les mesures les plus larges. La cause initiale : la compromission du compte GitHub du mainteneur principal derrière la bibliothèque keyv, un moteur de stockage clé-valeur universel affiché à 127 millions de téléchargements hebdomadaires selon les statistiques npm au moment de l'incident.

Le même développeur étant responsable de l'ensemble de l'écosystème gravitant autour de keyv — notamment cacheable (29 millions de téléchargements/mois), flat-cache (565 millions/mois) et file-entry-cache (557 millions/mois) — l'attaquant a pu, depuis un seul point d'entrée, propager le ver à l'ensemble des dépôts connexes contrôlés par ce compte. Le mécanisme est simple mais redoutable : une fois en possession des accès GitHub, l'intrus pousse directement des fichiers malveillants sur la branche principale, déclenche immédiatement une nouvelle release, et le workflow GitHub Actions signe automatiquement la version empoisonnée avec une provenance valide. Le registre npm reçoit alors un paquet techniquement légitime aux yeux de tous les outils de vérification de provenance standard, y compris ceux conformes au cadre SLSA.

Sur le plan technique, le ver s'appuie sur un script preinstall injecté dans le manifeste package.json. Ce script est exécuté par le gestionnaire de paquets avant l'installation du code du projet lui-même, lors de tout npm install ou npm ci. La charge utile cible un spectre large de secrets présents dans l'environnement de build ou sur le poste du développeur : tokens GitHub et GitLab, credentials AWS et GCP, tokens de registres privés npm, PyPI et Maven, chaînes de connexion à des bases de données PostgreSQL, MySQL et MongoDB, ainsi que clés privées SSH et PGP stockées dans les répertoires standard. Toutes ces données sont exfiltrées vers un serveur de commande et contrôle externe avant que l'installation ne reprenne normalement, rendant la compromission quasi invisible lors de l'exécution du pipeline de build.

La caractéristique la plus préoccupante de cette attaque réside dans ses mécanismes de persistance secondaire. En parallèle des scripts preinstall, l'attaquant a committé des fichiers de hooks pour VS Code et Claude Code directement dans les dépôts source compromis. Ces fichiers sont lus par les IDE au moment de l'ouverture du projet, sans qu'aucun npm install ne soit nécessaire. Un développeur qui clone le dépôt affecté et ouvre simplement son éditeur active la charge utile avec ses propres privilèges système. Ce vecteur secondaire transforme une attaque classique de supply chain en un risque persistant qui touche les workstations de développement elles-mêmes, bien au-delà des serveurs CI/CD.

Les chiffres définitifs varient selon les firmes d'analyse. SafeDep, dont les données sont les plus citées par la communauté, confirme 353 versions empoisonnées dans 79 noms de paquets sur npm au moment de son rapport initial du 4 août 2026. Aikido Security rapporte une empreinte plus large : au moins 868 paquets distincts touchés, couvrant 1 381 versions au total. Wiz estime que les seuls paquets du namespace keyv au sens strict sont présents dans plusieurs dizaines de millions de projets Node.js actifs à différentes profondeurs de leur arbre de dépendances, ce qui rend l'impact potentiel considérable même si tous les projets n'ont pas effectué une installation des versions malveillantes dans la fenêtre de compromission.

La réaction de la communauté a été rapide. npm a commencé à dépublier les versions malveillantes en soirée du 4 août, quelques heures après les premières alertes coordonnées des firmes de sécurité. Le mainteneur légitime a repris le contrôle de son compte GitHub, régénéré l'ensemble de ses tokens d'accès et publié des versions saines portant la mention patched dans le changelog avant minuit. GitHub a de son côté activé des mesures de protection supplémentaires sur le compte compromis et notifié les projets ayant forké les dépôts touchés.

Les chercheurs de Snyk recommandent de considérer comme potentiellement compromise toute machine ayant effectué un npm install d'une version affectée entre le 4 et le 5 août 2026. La priorité absolue est la rotation de l'ensemble des secrets d'environnement présents sur ces machines et dans les pipelines CI/CD correspondants : tokens GitHub, clés cloud, mots de passe de bases de données, tokens d'API. Selon Wiz, il faut également auditer les fichiers de configuration d'IDE dans tous les projets clonés depuis ces dépôts durant la période de compromission, notamment les répertoires .vscode/ et .claude/.

L'incident rappelle de façon troublante l'attaque sur xz-utils de 2024, qui avait failli introduire une backdoor dans OpenSSH via un mainteneur manipulé sur plusieurs mois. Ici, la technique est différente — compromission directe de compte plutôt qu'ingénierie sociale longue durée — mais la surface d'impact est bien plus large en raison de la concentration extrême du graphe de dépendances JavaScript autour d'un nombre très restreint de mainteneurs individuels. La nature de ver, qui s'est propagé automatiquement à l'ensemble des espaces de noms contrôlés par le même compte, constitue également une évolution notable par rapport aux attaques de supply chain npm précédentes, qui ciblaient généralement un ou deux paquets isolés.

Pourquoi cet incident redéfinit la surface d'attaque des pipelines CI/CD modernes

L'attaque keyv s'inscrit dans une tendance structurelle qui préoccupe depuis plusieurs années les équipes de sécurité DevSecOps : la concentration des écosystèmes open source autour d'un nombre restreint de mainteneurs individuels crée des points de défaillance unique à l'échelle de l'industrie. Selon les données de l'OpenSSF, une part significative des paquets npm les plus téléchargés est maintenue par une seule personne, souvent bénévolement. La compromission d'un seul compte utilisateur devient ainsi une arme de destruction massive silencieuse, capable d'atteindre simultanément des milliers d'équipes de développement dans le monde entier sans aucune interaction de leur part.

La CISA et l'ANSSI ont toutes deux insisté, dans leurs guides 2025 sur la sécurité de la chaîne d'approvisionnement logicielle, sur la nécessité pour les organisations de mettre en place des politiques de verrouillage des dépendances par hash dans les lockfiles, d'audit automatisé des scripts preinstall, et de scan continu des artefacts de build. Cet incident démontre que ces mesures, si elles avaient été généralisées, auraient limité mécaniquement la propagation : un pipeline dont le package-lock.json est engagé et vérifié en intégrité cryptographique ne télécharge pas automatiquement une version supérieure empoisonnée publiée après la dernière validation.

Le vecteur IDE est particulièrement problématique pour les environnements d'entreprise. Les politiques de sécurité des endpoints se concentrent traditionnellement sur les navigateurs et les clients de messagerie comme principales surfaces d'entrée. Les hooks d'IDE, exécutés avec les privilèges complets de l'utilisateur connecté, représentent un angle mort dans la plupart des architectures EDR actuelles. Cette attaque devrait conduire les équipes de sécurité à revoir leurs politiques de configuration des environnements de développement, à activer les restrictions d'exécution de code dans VS Code via le paramètre workspace.trust, et à auditer les fichiers de configuration des outils d'assistance IA intégrés aux IDEs.

Sur le plan réglementaire, le règlement européen CRA (Cyber Resilience Act), dont les exigences principales entrent progressivement en vigueur en 2026-2027, impose aux fabricants de produits numériques de documenter et surveiller leur chaîne de dépendances logicielles. Les entreprises qui distribuent des logiciels s'appuyant sur keyv ou ses dérivés et qui n'ont pas de processus d'inventaire SBOM (Software Bill of Materials) opérationnel seront en difficulté pour démontrer leur conformité et leur réactivité en cas d'audit post-incident.

Ce qu'il faut retenir

• Toute machine ayant exécuté npm install avec une version affectée de keyv, cacheable, flat-cache ou file-entry-cache entre le 4 et le 5 août 2026 doit être considérée compromise — rotation immédiate de tous les secrets d'environnement.
• Les hooks IDE déposés dans les dépôts permettent l'exécution de la charge utile sans npm install ; auditer les répertoires .vscode/ et .claude/ dans tous les projets clonés depuis ces dépôts durant la période de compromission.
• Mettre en place un pinning de dépendances par hash dans tous les pipelines CI/CD et activer l'audit automatisé des scripts preinstall via des outils tels que Socket.dev, Snyk ou Wiz.