Ver npm « Shai-Hulud » : l’opération Chaindrop compromet keyv, 444 paquets infectés, 2 milliards d’installs mensuels touchés
Panos Petropoulos
Expert développement web · 23 août 2026 · 16 min de lecture
TL;DR — L’essentiel en 30 secondes
- • Le 4 août 2026, un attaquant compromet le compte GitHub du mainteneur de keyv (127M téléchargements npm/semaine) et de la famille cacheable (29M).
- • Il publie
keyv@6.0.0avec un hook preinstall malveillant et déclenche les GitHub Actions pour auto-publier des versions infectées sur npm. - • Le payload : un ver baptisé Shai-Hulud qui vole les identifiants npm, GitHub, cloud (AWS/GCP/Azure), Kubernetes et HashiCorp Vault.
- • Le ver s’auto-propage : chaque token npm volé est utilisé pour infecter d’autres paquets. Résultat : 444 paquets, 2+ milliards d’installs mensuels.
- • Paquets clés :
keyv,cacheable,flat-cache(565M),file-entry-cache(557M). - • Sources : Sygnia, Upwind, Elastic Security Labs, Datadog, CSA Singapore.
C’est l’incident le plus grave de l’histoire de la supply chain npm. Le 4 août 2026, un attaquant — probablement un groupe organisé selon Sygnia — a compromis le compte GitHub derrière les bibliothèques keyv et cacheable, deux piliers invisibles de l’écosystème JavaScript. En exploitant les workflows GitHub Actions du mainteneur, l’attaquant a déclenché la publication automatique de versions vérolées sur le registre npm — sans même avoir besoin d’un token npm direct. Le ver embarqué, baptisé « Shai-Hulud » par la communauté sécurité, s’est ensuite propagé de manière autonome : chaque machine infectée devenait un vecteur de publication pour d’autres paquets.
En moins de 48 heures, 444 paquets npm avaient été compromis, totalisant plus de 2 milliards d’installations mensuelles. Parmi eux : flat-cache (565 millions de téléchargements cumulatifs) et file-entry-cache (557 millions), utilisés par ESLint, Prettier, webpack, et des centaines d’autres outils que chaque développeur JavaScript français utilise au quotidien.
Ce qui distingue Chaindrop des attaques supply chain précédentes — event-stream (2018), ua-parser-js (2021), la première vague Mini Shai-Hulud sur TanStack en mai 2026 — c’est la convergence de trois innovations offensives : la compromission des workflows CI/CD comme vecteur de publication, l’exfiltration d’identifiants cloud et Kubernetes en plus des tokens npm, et la vitesse de propagation exponentielle. Cet article décortique le mécanisme, établit la timeline, mesure l’impact et détaille les contre-mesures pour les équipes open source francophones.
La chaîne d’attaque Chaindrop : du compte GitHub au ver
La séquence d’attaque repose sur cinq phases distinctes, chacune exploitant une faiblesse structurelle différente de l’écosystème. D’après l’analyse conjointe de Sygnia et Upwind, le vecteur initial était une compromission du compte GitHub du mainteneur — vraisemblablement via un token d’accès personnel (PAT) fuité ou volé par un infostealer. Aucune authentification à deux facteurs matérielle (WebAuthn/FIDO2) n’était activée sur le compte.
Une fois le compte GitHub en main, l’attaquant n’a pas publié directement sur npm. Il a modifié le code source de keyv en ajoutant deux fichiers (setup.mjs et Math_Symbol.js) et un script "preinstall": "node setup.mjs" dans le package.json. Puis il a poussé un commit tagé v6.0.0. Le workflow GitHub Actions configuré pour publier automatiquement les tags sur npm s’est déclenché. C’est le CI/CD légitime qui a publié le paquet malveillant.
Le même scénario s’est répété sur cacheable et ses sous-paquets. En ciblant les deux familles simultanément, l’attaquant a maximisé la fenêtre d’exposition : les développeurs qui avaient verrouillé keyv mais pas cacheable (ou inversement) étaient touchés quand même.
Chaîne d’attaque Chaindrop — Du compte GitHub au ver auto-propagateur
L’utilisation de GitHub Actions comme vecteur de publication représente un saut qualitatif majeur. Dans les attaques précédentes (event-stream, Injective Labs), l’attaquant devait obtenir un token npm. Ici, il a utilisé l’infrastructure CI/CD légitime du projet. Le paquet publié portait la signature de provenance du workflow officiel — ce qui signifie que npm audit signatures le validait comme authentique. La confiance dans les attestations de provenance, que nous recommandions encore le mois dernier, vient d’être sérieusement ébranlée.
Le payload Math_Symbol.js, selon Elastic Security Labs, était fortement obfusqué avec des couches de Base64 et d’évaluation dynamique. Il ciblait huit catégories de secrets : les fichiers ~/.npmrc et ~/.yarnrc, les clés SSH (~/.ssh/), les variables d’environnement cloud (AWS_ACCESS_KEY, GOOGLE_APPLICATION_CREDENTIALS, AZURE_CLIENT_SECRET), les kubeconfigs (~/.kube/config), les tokens HashiCorp Vault, les identifiants Docker (~/.docker/config.json), et les fichiers .env de chaque projet trouvé dans le répertoire courant.
Notre avis d’expert n° 1 : le CI/CD est devenu le nouveau vecteur principal
Avis d’expert #1 — GitHub Actions transforme un compte compromis en clé de publication universelle
Le basculement le plus dangereux de Chaindrop est l’utilisation de GitHub Actions comme vecteur de publication. Jusqu’ici, compromettre un compte GitHub et compromettre la publication npm étaient deux opérations distinctes. Avec les workflows de publication automatisée — que GitHub et npm encouragent activement pour la provenance — ces deux surfaces d’attaque n’en font plus qu’une. L’attaquant n’a eu besoin d’aucun token npm : le workflow CI/CD l’a généré et utilisé pour lui. Pire, le paquet résultant porte une attestation de provenance valide, ce qui le rend invisible aux vérifications que nous recommandions hier. La leçon est brutale : la provenance atteste de l’origine du build, pas de l’intégrité du code source. Tant que la protection du compte qui contrôle le dépôt source n’est pas au niveau — WebAuthn obligatoire, revue de code multi-signataires, branch protection stricte — la chaîne de confiance reste rompue.
Chez D-Open, nous avons immédiatement audité nos propres workflows de publication après l’annonce. Le constat est clair : plus de 60 % des projets open source francophones que nous accompagnons utilisent des workflows GitHub Actions qui publient sur npm lors d’un tag push — exactement le schéma exploité par Chaindrop. La plupart n’ont pas de branch protection rules, pas de required reviews sur les tags, et pas d’environnement de déploiement GitHub avec approbation manuelle.
La contre-mesure immédiate est d’ajouter un environnement de déploiement GitHub avec approbation manuelle obligatoire pour tout workflow qui publie sur un registre de paquets. Cela ajoute une étape humaine dans la chaîne — un développeur doit explicitement approuver la publication dans l’interface GitHub avant que le workflow ne puisse s’exécuter. C’est un compromis entre vélocité et sécurité, mais après Chaindrop, le choix n’en est plus un.
Timeline : 48 heures de crise
La séquence chronologique, reconstituée à partir des publications de Sygnia, Upwind et des logs npm, révèle une opération chirurgicale exécutée avec une précision rare. L’attaquant a frappé un samedi — quand les équipes sécurité sont en effectif réduit — et a exploité la fenêtre du week-end pour maximiser le temps de propagation avant détection.
Chronologie de l’opération Chaindrop
Le délai entre la publication de keyv@6.0.0 (02h12 UTC) et la première alerte publique (19h42 UTC) est de 17 heures et 30 minutes. Pendant cette fenêtre, chaque npm install ou npm ci qui résolvait keyv sans version épinglée dans le lockfile téléchargeait la version malveillante. Avec 127 millions de téléchargements hebdomadaires, le nombre d’installations pendant la fenêtre d’exposition se chiffre en centaines de milliers.
Le fait que l’attaque ait eu lieu un samedi n’est pas anodin. L’analyse de Datadog montre que les attaques supply chain lancées le week-end ont un temps de détection moyen 3,4 fois plus long que celles lancées en semaine. Pour les équipes françaises en heure d’été (UTC+2), la publication à 02h00 UTC signifie 04h00 du matin — le creux absolu de la vigilance.
Notre avis d’expert n° 2 : la propagation exponentielle change la nature du risque
Avis d’expert #2 — Le passage de la supply chain linéaire au ver exponentiel
Jusqu’en 2025, les attaques supply chain npm étaient linéaires : un attaquant compromettait un paquet, et les dégâts étaient proportionnels au nombre de dépendants de ce seul paquet. Shai-Hulud est exponentiel. Chaque machine infectée devient un vecteur : les tokens npm volés permettent de publier des versions corrompues de tous les paquets auxquels le développeur a accès en écriture. La vitesse de propagation n’est plus limitée par l’attaquant mais par le nombre de mainteneurs qui exécutent npm install. C’est un modèle biologique, pas un modèle de hacking : l’organisme se réplique, mute et s’adapte. La réponse doit être épidémiologique : isoler, tracer les contacts, révoquer, puis vacciner.
L’analyse de la propagation montre trois vagues distinctes. La première vague (02h-06h UTC) correspond aux publications directes par l’attaquant via les workflows CI/CD compromis : 14 paquets de la famille keyv/cacheable. La deuxième vague (06h-12h UTC) est la propagation automatique du ver : les développeurs qui ont exécuté npm install le matin ont vu leurs tokens volés, et le ver a publié environ 130 nouvelles versions corrompues. La troisième vague (12h-19h UTC) a ajouté encore 300 paquets — la progression géométrique.
Pour comprendre l’échelle, comparons avec les attaques précédentes de la famille Shai-Hulud. En mai 2026, la première variante sur TanStack avait touché 169 paquets avec 518 millions de téléchargements. Chaindrop multiplie ces chiffres par 2,6 pour les paquets et par 3,8 pour les installations. L’évolution est nette et inquiétante.
Votre pipeline CI/CD publie-t-il sur npm à chaque tag ?
C’est exactement le vecteur exploité par Chaindrop. Nous auditons vos workflows GitHub Actions, vos branch protection rules et vos environnements de déploiement. Premier diagnostic gratuit.
Auditer mes workflows CI/CD →Comparaison d’impact : Chaindrop dans l’histoire des attaques npm
Pour mesurer la gravité relative de Chaindrop, nous avons compilé les données des sept attaques supply chain npm les plus significatives de 2018 à 2026. Le tableau ci-dessous rapporte le nombre de paquets directement compromis, le volume d’installations mensuelles impactées, et le temps entre la publication malveillante et la première alerte publique.
Attaques supply chain npm majeures — Comparaison d’impact
Le saut d’échelle est frappant. De 2018 à 2022, les attaques supply chain npm ciblaient un ou deux paquets. L’attaque Injective Labs de juillet 2026 a marqué un premier palier avec 18 paquets. Mini Shai-Hulud sur TanStack a franchi le cap des 169 paquets en mai 2026. Chaindrop, trois mois plus tard, atteint 444 paquets — une croissance de 163 % en un trimestre.
La différence qualitative est encore plus significative que la différence quantitative. Les attaques historiques volaient des clés de portefeuilles crypto ou des variables d’environnement. Chaindrop exfiltre des identifiants d’infrastructure — Kubernetes, Vault, Docker, clouds publics — qui permettent des compromissions bien au-delà du code JavaScript. Un kubeconfig volé donne accès à un cluster entier. Un token Vault donne accès à tous les secrets de l’organisation.
Notre avis d’expert n° 3 : l’exfiltration cloud/K8s transforme un incident npm en compromission d’infrastructure
Avis d’expert #3 — Le rayon d’impact dépasse désormais l’écosystème JavaScript
Le ciblage de kubeconfigs, tokens Vault et identifiants cloud dans le payload Shai-Hulud représente un changement stratégique. L’attaquant ne cherche plus seulement à compromettre des paquets npm — il utilise npm comme vecteur d’entrée dans l’infrastructure. Un développeur qui exécute npm install sur une machine qui a accès au cluster de production expose l’ensemble de l’infrastructure Kubernetes. Ce n’est plus un problème de sécurité applicative — c’est un problème de sécurité d’entreprise. Les RSSI français qui classaient les attaques npm comme un risque « développeur » doivent requalifier immédiatement. La surface d’attaque réelle est l’infrastructure, pas le code.
D’après l’analyse d’Upwind, le payload cible spécifiquement les environnements de développement qui ont un accès direct aux clusters Kubernetes de production — une pratique courante dans les startups et les PME françaises où le cloisonnement des environnements est souvent insuffisant. L’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI) recommande depuis 2024 un cloisonnement strict entre les postes de développement et les accès de production. Chaindrop vient de démontrer pourquoi.
Pour les équipes qui déploient sur Kubernetes, notre guide sur la sécurisation des pipelines CI/CD détaille comment isoler les secrets de production des environnements de build. Et l’article sur les 7 étapes de sécurisation des dépendances npm couvre la configuration de ignore-scripts, les vérifications de provenance et la génération de SBOM.
6 actions immédiates pour les équipes françaises
Si vous maintenez ou déployez des projets JavaScript/TypeScript, voici les actions à exécuter aujourd’hui, classées par priorité décroissante.
Action 1 — Auditer l’exposition
Exécutez npm ls keyv cacheable flat-cache file-entry-cache dans chaque projet. Vérifiez les versions dans package-lock.json : keyv@6.0.0 et cacheable@1.9.0 sont les versions malveillantes. Recherchez setup.mjs et Math_Symbol.js dans node_modules.
Action 2 — Épingler les versions propres
Forcez les versions propres dans package.json : keyv@5.2.3 (dernière version sûre) et cacheable@1.8.7. Ajoutez les overrides npm pour les dépendances transitives. Exécutez npm ci et vérifiez que le lockfile ne référence plus les versions compromises.
Action 3 — Désactiver les scripts d’installation
Ajoutez ignore-scripts=true dans votre .npmrc projet et global. Pour les rares paquets qui nécessitent des scripts d’installation légitimes (binaires natifs comme sharp, bcrypt), ajoutez-les explicitement dans un script post-install ciblé.
Action 4 — Faire tourner tous les secrets
Si une machine a exécuté npm install entre le 4 et le 6 août 2026, considérez tous les secrets présents sur cette machine comme compromis. Tokens npm, clés SSH, identifiants cloud, kubeconfigs, tokens Vault, fichiers .env — tout doit être révoqué et regenéré.
Action 5 — Auditer les GitHub Actions
Vérifiez les runs de vos workflows GitHub Actions entre le 4 et le 6 août. Recherchez des publications npm non autorisées. Si votre workflow publie sur npm lors d’un tag push, ajoutez immédiatement un environnement de déploiement GitHub avec approbation manuelle.
Action 6 — Générer un SBOM à jour
Pour la conformité NIS2 et la traçabilité : générez un SBOM CycloneDX à jour avec npx @cyclonedx/cyclonedx-npm --output-file sbom.cdx.json. Archivez-le avec le numéro de build. En cas d’audit réglementaire, vous pourrez prouver l’état exact de vos dépendances au moment du build.
Notre avis d’expert n° 4 : la provenance npm ne suffit plus — il faut la provenance du code source
Avis d’expert #4 — La confiance ne peut plus reposer sur un seul maillon
Chaindrop démontre que les attestations de provenance npm, dans leur forme actuelle, ne protègent pas contre la compromission du code source. Le paquet keyv@6.0.0 portait une attestation Sigstore valide parce qu’il avait été construit par le workflow CI/CD officiel du dépôt. Le problème est que le code source lui-même était corrompu. Il manque un maillon dans la chaîne de confiance : la vérification que le code source commité a été revu et approuvé par un humain autorisé, pas simplement poussé par un compte qui a accès. Les branch protection rules de GitHub, avec required reviews et required approvals, sont la solution existante — mais moins de 20 % des paquets npm les plus téléchargés les activent. Après Chaindrop, la provenance doit devenir tri-dimensionnelle : qui a écrit le code (revue signée), qui a approuvé le merge (second signataire), et quel workflow a construit le paquet (attestation CI).
Cette analyse rejoint les recommandations publiées par la Linux Foundation en juillet 2026, qui a lancé un programme de 12,5 millions de dollars pour la sécurité open source. L’un des axes prioritaires est précisément la mise en place de signatures multi-parties pour les publications de paquets critiques.
Pour les mainteneurs français de paquets npm, nous recommandons trois mesures structurelles : activer les branch protection rules avec au moins un reviewer requis sur la branche principale, configurer un environnement de déploiement GitHub avec approbation manuelle pour le workflow de publication, et activer WebAuthn/FIDO2 (clé matérielle) sur le compte GitHub. Ces trois mesures auraient bloqué Chaindrop à chacune des trois phases de l’attaque.
Impact sur l’écosystème open source français
La France compte environ 380 000 développeurs JavaScript/TypeScript actifs (estimation France Num 2026). La quasi-totalité de leurs projets dépendent, directement ou transitivement, d’au moins un paquet de la famille keyv/cacheable. flat-cache et file-entry-cache sont des dépendances d’ESLint — l’outil de linting utilisé dans plus de 90 % des projets JavaScript français. Autrement dit : si vous avez exécuté npm install dans un projet avec ESLint pendant la fenêtre d’exposition, vous êtes potentiellement touché.
Les conséquences réglementaires sont immédiates. La directive NIS2, transposée en droit français depuis 2024, impose aux entités essentielles et importantes de notifier l’ANSSI dans les 24 heures suivant la détection d’un incident de sécurité significatif. Si une équipe a utilisé des paquets compromis en production et que des secrets cloud ou K8s ont été exfiltrés, l’incident entre dans le périmètre de notification obligatoire. Notre article sur la conformité NIS2 pour les PME détaille les obligations et les délais.
L’autre dimension est le rapport OSSRA 2026 publié par Synopsys, que nous avons analysé dans un article dédié. Le rapport montrait que 87 % des codebases auditées contenaient des composants open source avec des vulnérabilités connues. Chaindrop ajoute une dimension : il ne s’agit plus de vulnérabilités passives mais de compromissions actives par un adversaire organisé. Le modèle de menace des équipes françaises doit être mis à jour en conséquence.
Le rapport Verizon DBIR 2026, qui a documenté le doublement des attaques supply chain, prend avec Chaindrop une résonance particulière. Les chiffres 2026 devront être revisés à la hausse.
Ce que Chaindrop révèle sur l’avenir de la supply chain npm
Chaindrop n’est pas un événement isolé. C’est la troisième itération d’un malware qui évolue. De la vague de 317 paquets en mai 2026 à l’attaque TanStack (169 paquets), puis à Chaindrop (444 paquets), la trajectoire est claire : les attaquants gagnent en sophistication, en échelle et en vitesse à chaque itération.
Trois tendances émergent de cet incident. Premièrement, le CI/CD comme surface d’attaque : les workflows de publication automatisée, conçus pour la vitesse et la traçabilité, deviennent un vecteur privilégié. Deuxièmement, l’élargissement du rayon d’impact : du vol de tokens npm au vol d’identifiants d’infrastructure, l’attaquant cible désormais l’ensemble de l’écosystème technologique de la victime. Troisièmement, la vitesse de propagation exponentielle : le modèle du ver rend les mécanismes de réponse linéaires insuffisants.
Pour les équipes qui souhaitent approfondir la sécurisation de leurs dépendances, consultez également notre guide Comment sécuriser votre pipeline npm contre les attaques supply chain en 7 étapes, mis à jour après Chaindrop, ainsi que notre analyse de l’incident Phantom-Gyp et Miasma de juin 2026, qui préfigurait plusieurs des techniques utilisées dans Chaindrop.
Questions fréquentes
Quelle différence entre Shai-Hulud et Mini Shai-Hulud ?
« Mini Shai-Hulud » désigne la première variante du ver, détectée en mai 2026 lors de l’attaque TanStack. Elle se propageait exclusivement via des tokens npm statiques et ciblait les identifiants de registres de paquets. « Shai-Hulud » (sans le préfixe Mini) est la variante évoluée déployée dans l’opération Chaindrop d’août 2026. Elle ajoute trois capacités : l’exfiltration d’identifiants Kubernetes et HashiCorp Vault, la propagation via GitHub Actions (au lieu de tokens npm directs), et un mécanisme d’obfuscation à couches multiples plus difficile à détecter par analyse statique.
Combien de paquets npm ont été compromis dans l’opération Chaindrop ?
Au total, 444 paquets npm ont été compromis, représentant plus de 2 milliards d’installations mensuelles. Les paquets les plus critiques sont keyv (127 millions de téléchargements par semaine), cacheable (29 millions), flat-cache (565 millions cumulatifs) et file-entry-cache (557 millions cumulatifs). La propagation a touché en cascade plus de 400 paquets secondaires via les dépendances transitives et les tokens npm volés sur les machines infectées.
Comment vérifier si mon projet est exposé à Chaindrop ?
Trois vérifications : 1) Exécutez npm ls keyv cacheable flat-cache file-entry-cache pour détecter la présence de ces paquets dans votre arbre de dépendances. 2) Vérifiez les versions dans package-lock.json : keyv@6.0.0, cacheable@1.9.0 et versions ultérieures sont les versions compromises. 3) Recherchez les fichiers setup.mjs et Math_Symbol.js dans vos node_modules. Analysez également vos logs GitHub Actions entre le 4 et le 6 août 2026 pour détecter des publications npm non autorisées.
Quelles actions immédiates pour les équipes françaises ?
Six actions prioritaires : 1) Auditez tous vos package-lock.json contre la liste des 444 paquets compromis (publiée par Socket). 2) Épinglez keyv et cacheable sur les dernières versions propres. 3) Activez ignore-scripts=true dans .npmrc. 4) Faites tourner tous les tokens npm, clés SSH, identifiants cloud et secrets CI/CD exposés. 5) Auditez les workflows GitHub Actions pour détecter des runs non autorisés et ajoutez un environnement de déploiement avec approbation manuelle. 6) Générez un SBOM CycloneDX à jour pour conformité NIS2.
Votre équipe est-elle exposée à Chaindrop ?
Sprint D-Open de 2 semaines : audit complet des dépendances npm et des workflows GitHub Actions, analyse des secrets exposés, plan de rotation, cloisonnement CI/CD production. Rapport NIS2-compliant. Formation équipe incluse.
Lancer le sprint sécurité supply chain →Sources : Sygnia (rapport technique Chaindrop), Upwind (analyse propagation), Elastic Security Labs (analyse payload), Datadog Security Labs (corrélation temporelle), CSA Singapore (advisory national), Socket, Snyk — publiées entre le 4 et le 8 août 2026. Cet article propose une lecture opérationnelle pour les équipes de développement open source francophones ; il ne reproduit aucun élément permettant l’exploitation du malware.