ChainDrop : provenance valide dans plus de 400 paquets npm, et des hooks Claude Code qui ne nécessitent pas de npm install

Le 4 août 2026, des attaquants ont pris le contrôle du compte GitHub derrière keyv, une bibliothèque de mise en cache que Elastic Security Labs affirme avoir été téléchargée plus de 600 millions de fois le mois précédent. Wiz Research et Orca Security rapportent tous deux que des fichiers malveillants ont été poussés directement sur la branche principale de keyv, et que le workflow GitHub Actions du projet a ensuite construit et publié la version empoisonnée — de sorte qu'elle a atteint npm en bénéficiant d'une provenance valide, l'outillage d'attestation de la chaîne d'approvisionnement utilisé pour déterminer qu'un paquet est fiable. Un ver auto-propageant que les chercheurs appellent ChainDrop a ensuite utilisé des jetons npm volés pour répéter l'opération sur les paquets d'autres mainteneurs : Elastic a recensé plus de 400 paquets uniques au 6 août, Microsoft Threat Intelligence a décrit la même campagne le 4 août, et l'Agence de cybersécurité de Singapour a recensé plus de 1 300 versions de paquets compromises totalisant 2 milliards de téléchargements mensuels. Elastic et Microsoft décrivent tous deux des hooks qui se réexécutent lorsqu'un dépôt est ouvert dans Claude Code ou Visual Studio Code. La liste complète des sources, la note de gravité et l'évaluation de confiance de la fiche figurent dans l'archive des incidents IA, aux côtés des autres entrées liées à npm et à l'outillage des développeurs enregistrées autour d'elle.

Comment un pipeline de publication légitime a signé sa propre compromission

Wiz Research reconstitue les premières minutes : à partir du 4 août à 09:00 UTC l’attaquant a utilisé une identité compromise pour introduire des charges utiles de persistance pour IDE dans le dépôt keyv, puis, peu après, a publié une nouvelle version de keyv contenant la charge utile. Wiz identifie la partie compromise comme un compte de mainteneur GitHub et indique que plusieurs paquets de l’écosystème keyv et cacheable ont suivi.

Le compte rendu à réaction rapide d’Orca Security est plus précis sur le chemin de signature. Selon celui-ci, l’attaquant a poussé deux fichiers malveillants — setup.mjs et Math_Symbol.js — directement vers la branche principale et a immédiatement publié de nouvelles versions. Comme ces versions ont été construites via les workflows GitHub Actions du compte compromis, les versions empoisonnées ont été publiées sur npm avec des signatures de provenance valides, contournant les contrôles d’intégrité standard de la chaîne d’approvisionnement. Zscaler ThreatLabz, une équipe de recherche indépendante qui ne figure pas parmi les sources citées dans le rapport, parvient à la même conclusion et en précise le niveau : le keyv 6.0.0 malveillant portait une provenance valide de niveau SLSA Build Level 3 parce que l’attaquant contrôlait le dépôt source. BleepingComputer, qui a signalé la campagne le jour même, consigne le même mécanisme — des fichiers malveillants poussés directement vers les branches principales des projets, de nouvelles versions générées, une provenance valide parce que les builds s’exécutaient via des workflows GitHub Actions légitimes.

L'analyse de Microsoft ajoute un détail qui ressemble à une contradiction sans en être une. Lors de la phase de propagation du ver, Microsoft Threat Intelligence a constaté que de nombreuses versions malveillantes n'avaient aucun commit de code source, aucune pull request, aucun tag ni aucune version légitime correspondants, ce qui indiquait que les attaquants avaient modifié et publié directement des tarballs de paquets plutôt que de compromettre chaque dépôt public de code source. Lus ensemble, les sources décrivent deux régimes de signature au sein d'une même campagne : les premières versions de keyv ont transité par le véritable pipeline CI de la victime et portent des attestations qui en garantissent l'authenticité, tandis que les versions ultérieures du ver ont été en grande partie assemblées et publiées avec des jetons de registre volés, sans laisser la moindre trace dans le code source. L'observation de Microsoft est que le schéma de publication directe des tarballs explique pourquoi les versions malveillantes apparaissaient fréquemment comme une simple incrémentation de version de correctif, sans commits de code source ni pull requests correspondants.

La leçon inconfortable est énoncée sans détour par Zscaler : la provenance valide le processus de compilation, non l'identité du compte ni l'intégrité du système d'intégration continue qui l'exécute. Elle reconnaît aussi une lacune qui compte pour quiconque reconstitue l'incident — le mécanisme exact de prise de contrôle de compte employé par l'attaquant était inconnu au moment de son analyse.

Ce qui s'exécute lors de npm install : preinstall, Bun 1.3.13, et un collecteur à 300 motifs

Elastic Security Labs décrit le déclencheur comme un preinstall hook dans package.json, qui exploite à mauvais escient une fonctionnalité npm légitime exécutant des commandes arbitraires avant qu'un package ait fini de s'installer, sans nécessiter d'interaction supplémentaire de la victime. Le hook lance setup.mjs, qui vérifie si le runtime JavaScript Bun est déjà présent. S'il ne l'est pas, le dropper détecte la plateforme et l'architecture de la machine, télécharge Bun v1.3.13 depuis la page de publication officielle, l'extrait, l'utilise pour exécuter la charge utile, puis supprime le répertoire temporaire pour effacer ses traces. Wiz a identifié indépendamment l'agent utilisateur Bun/1.3.13 à l'origine des appels malveillants. Le dropper est multiplateforme, ciblant Linux, macOS et Windows.

La charge utile est fortement obfusquée, et les sources diffèrent légèrement sur sa taille : Elastic l'estime à 711 kilo-octets, Orca Security à 728 Ko. Elle utilise un aplatissement du flux de contrôle et un schéma d'encodage de chaînes en Base91, et contient des chaînes à thème Dune — laza, kanly, ghola, mentat, lasgun, sietch, fedaykin, tleilaxu, sandworm, sardaukar, ornithopter, navigator — dont Elastic note qu'elles présentent des similitudes avec les précédentes campagnes Shai-Hulud.

Le compte rendu comportemental de Microsoft ajoute deux détails utiles. La charge utile vérifie d'abord son environnement et s'arrête sur les systèmes en langue russe, évite les instances en double et démarre une copie en arrière-plan détachée sur les postes de travail des développeurs ; au sein de la CI, elle reste attachée à la tâche active afin de pouvoir accéder aux secrets de workflow, aux identifiants des runners et aux autorisations de publication OpenID Connect.

Le collecteur est le point où l'incident devient une affaire d'outillage IA plutôt qu'une histoire générique d'identifiants. Elastic indique qu'il scanne plus de 300 motifs uniques dans les stockages d'identifiants sur une machine de développeur, et que le ciblage notable vise les identifiants d'outils IA : Anthropic, Claude, Codex, Cursor, OpenAI et Gemini. Il récupère aussi les identifiants AWS, GCP, Azure et Alibaba Cloud, les jetons d'accès personnels GitHub, les jetons JWT et de session, les jetons HashiCorp Vault, les clés privées SSH, les jetons de compte de service Kubernetes et les jetons npm. Wiz rapporte que la liste des cibles a été élargie de près de 70 % par rapport au code Mini Shai-Hulud antérieur sur lequel il repose, avec de nouveaux ajouts incluant les stockages d'identifiants d'agents IA pour Claude, OpenAI, Codex, Cursor et Gemini, les keystores de cryptomonnaies pour Foundry, Solana et Monero, le master.key de Jenkins, les secrets Argo CD et Harbor, les configurations CLI d'Alibaba et Tencent, ainsi que /etc/shadow.

Microsoft et Elastic décrivent tous deux le même schéma d'exfiltration. Les résultats sont sérialisés en JSON, compressés avec gzip et chiffrés avec une clé AES-256-GCM générée aléatoirement, et cette clé est enveloppée avec la clé publique RSA de l'attaquant. La charge utile ne code pas en dur son domaine de commande et de contrôle : Elastic indique qu'elle interroge un contrat intelligent Ethereum à 0xE1f2395ee43e45A1556EC6438a88c31B83493103 pour récupérer le point de terminaison actuel au moment de l'exécution, afin que l'infrastructure puisse être renouvelée sans toucher au logiciel malveillant. Si cela échoue, elle recherche un marqueur signé cryptographiquement — thebeautifulmarchoftime — dans l'historique des commits GitHub et valide le domaine par rapport à une clé RSA intégrée. Si les deux échouent, elle exfiltre via un dépôt GitHub public créé par le propre compte de la victime, décrit comme "Shai-Hulud: Here We Go Again". Microsoft signale qu'un chemin de repli encode un jeton GitHub volé en double Base64 plutôt que de le chiffrer.

La propagation est conditionnée par la qualité des jetons. Elastic indique que le ver ne s'active que lorsque le balayage des identifiants trouve un jeton npm doté de l'autorisation d'écriture sur les paquets et de la capacité à publier sans authentification à deux facteurs ; il télécharge ensuite le dernier tarball de chaque paquet accessible en écriture, s'y injecte, incrémente la version de patch et republie. BleepingComputer ajoute que chaque jeton est validé en temps réel auprès du point de terminaison whoami du registre avant d'être volé. C'est cette routine qui a transformé une seule identité compromise en des centaines de publications, et c'est pourquoi les versions malveillantes ressemblent à de simples incréments de patch.

Le chemin d’infection qui ne nécessite aucun npm install

Ce qui distingue cette campagne des précédents vers npm, c'est que l'installation n'est plus le seul point d'entrée. Elastic décrit deux chemins d'exécution supplémentaires destinés aux utilisateurs d'outils de codage IA. Un SessionStart hook dans .claude/settings.json exécute node .claude/setup.mjs lorsqu'une nouvelle session Claude démarre. Pour VS Code, une tâche folderOpen dans .vscode/tasks.json exécute node .vscode/setup.mjs lorsqu'un dépôt infecté est ouvert. L'analyse de Microsoft répertorie les mêmes quatre artefacts — .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json et .vscode/setup.mjs — et les décrit comme une voie d'infection secondaire qui peut redémarrer la charge utile après que l'installation npm initiale est terminée.

La condition qui amplifie considérablement ce phénomène réside dans les identifiants volés. Lorsqu'un jeton d'application GitHub figure parmi eux, Elastic indique que le ver commit les hooks malveillants dans jusqu’à 50 branches par dépôt accessible, en injectant .claude/settings.json et .vscode/tasks.json dans chacune. La conclusion d'Elastic est qu'un développeur qui clone l'une de ces branches et l'ouvre peut être infecté en ouvrant le projet — aucune installation de paquet, et donc aucune défense par script d'installation, n'intervient dans le processus.

L'évaluation de Zscaler est que les hooks de persistance survivent à la suppression du paquet et se réexécutent simplement en ouvrant le projet dans VS Code ou Claude Code, ce qui contourne --ignore-scripts l'atténuation que de nombreuses équipes ont adoptée après les précédents vers npm. Sa recommandation s'ensuit directement : traiter les fichiers de configuration des IDE et des agents d'IA — .claude/, .cursor/, .vscode/, .gemini/ — comme du code exécutable, revus avec la même rigueur que le code source.

Il existe une empreinte pour le volet dépôt de l’attaque. Elastic indique que les commits générés par le ver peuvent être identifiés par le nom d’auteur claude et le message de commit chore: update config, et Wiz relève la même chaîne de message. Elastic ajoute que le message de commit transportait également le jeton GitHub dérobé aux côtés d’une chaîne d’intimidation — IfYouBlockThisAPIKeyItWillCrashTheLiveProductionServersOfAllThirdPartyClients — qu’elle interprète comme une tentative de dissuader les développeurs de révoquer le jeton. Wiz relève la même chaîne dans les commits initiaux, le message plus court étant utilisé sur les commits qui introduisent les hooks IDE.

Les décomptes ne concordent pas, et ce n’est pas une contradiction.

Chaque chiffre publié concernant le rayon d'impact est rattaché à une unité différente, et ces unités ne sont pas interchangeables. Elastic Security Labs, dans un texte daté du 6 août, a dénombré plus de 400 paquets npm uniques compromis. Microsoft Threat Intelligence a décrit plus de 400 paquets répartis entre plusieurs éditeurs sans lien entre eux. Aikido, cité par BleepingComputer, avançait le chiffre de au moins 868 paquets sur 1 381 versions. Orca Security rapporte 10 paquets keyv et cacheable directement empoisonnés, cumulant plus de 619 millions de téléchargements mensuels, puis 868 paquets supplémentaires et 1 381 versions atteints par le ver, soit plus de 2 milliards d'installations mensuelles. L'avis AD-2026-009 du CSA de Singapour, daté du 6 août, recense plus de 1 300 versions de paquets compromises représentant un cumul de 2 milliards de téléchargements mensuels.

Il s’agit de trois dénominateurs différents — paquets, versions de paquets et volume mensuel de téléchargements — relevés à trois moments différents d’une campagne encore en cours. Le compte rendu de Zscaler sur la vitesse explique pourquoi ils divergent : il indique que le ver s’est auto-propagé jusqu’à plus de 400 paquets en moins de quatre heures et qu’au pic, il publiait environ un paquet infecté par seconde. Considérer un décompte ultérieur comme une correction d’un décompte antérieur serait erroné ; chacun est un instantané, et aucune des sources citées ne revendique de total final.

Les chiffres d'exposition d'Elastic au niveau des bibliothèques sont ceux qui sont le plus souvent cités et les moins ambigus. Il indique que keyv seul a dépassé les 600 millions de téléchargements le mois précédent, flat-cache approchant les 580 millions, cacheable-request plus de 137 millions, cacheable plus de 30 millions et cache-manager plus de 16 millions. L'avis de CSA énumère les versions compromises spécifiques, parmi lesquelles keyv 6.0.0, flat-cache 6.1.24, file-entry-cache 11.1.6, cacheable-request 13.0.20, cacheable 2.5.1, cache-manager 7.2.10, @cacheable/utils 2.5.1 et ecto 5.0.1.

Le piège de la révocation

Les intervenants qui ont installé une version affectée font face à un second problème après le premier. Elastic rapporte que, dans un chemin de repli conditionnel GitHub, la charge utile tente d’installer un composant de surveillance de jeton qui maintient l’accès aux identifiants et contient un gestionnaire destructeur si le jeton surveillé est révoqué. Zscaler décrit le mécanisme en détail opérationnel et le qualifie de piège de révocation de jeton : le ver installe un processus d’arrière-plan qui interroge l’API GitHub toutes les 60 secondes avec le jeton volé, et si le jeton renvoie une erreur 4xx — ce qui signifie que la victime l’a révoqué — une charge utile destructrice secondaire se déclenche, laquelle, selon la variante, peut inclure l’exécution de code à distance ou la suppression du répertoire personnel de l’utilisateur.

Wiz ajoute que l'interrupteur homme-mort est armé sélectivement en fonction d'une réponse du serveur de commande et contrôle : l'opérateur peut renvoyer une valeur spécifiant quelle commande armer et quel jeton l'interrupteur doit surveiller pour détecter une révocation. Wiz note également que le moniteur recherche une réponse valide provenant du point de terminaison utilisateur, de sorte que tout type de jeton valide à cet endroit peut servir de déclencheur.

La conséquence pratique est rapportée par BleepingComputer et par les recommandations d’Aikido qu’il cite : il convient de considérer comme compromis une station de travail de développeur ou un runner CI/CD ayant installé une version affectée même si le paquet a ensuite été supprimé, car l’exécution de la deuxième étape a pu exposer des jetons et compromettre l’intégrité de la compilation. Les recommandations de Microsoft aboutissent à la même conclusion du côté de la compilation, en avertissant que les organisations qui ont installé un paquet affecté avec les scripts de cycle de vie activés doivent considérer la station de travail ou le runner de compilation comme potentiellement compromis et reconstruire les systèmes affectés et les artefacts en aval à partir de sources fiables.

Ce qui est établi, ce qui est évalué, et ce que personne n'a démontré

Le document principal et cinq analyses indépendantes convergent sur la mécanique, et les affirmations mécaniques constituent la partie la plus solide du dossier.

• Le compte GitHub du mainteneur de keyv a été compromis, et des fichiers malveillants ont été poussés directement sur main avant qu’une version ne soit publiée, le 4 août 2026 — rapporté de manière concordante par Wiz, Orca Security, BleepingComputer et CSA Singapore.

• Au moins keyv 6.0.0 a atteint npm en passant par le propre pipeline CI de la victime, avec une provenance valide, Zscaler précisant une attestation SLSA Build Level 3. C’est l’affirmation qui rend cet incident notable, et elle est corroborée par trois organisations qui n’ont pas coécrit le travail des autres.

• Un hook de préinstallation a exécuté setup.mjs, qui a téléchargé Bun v1.3.13 et lancé une charge utile obfusquée qui a scanné plus de 300 modèles d'identifiants, y compris des identifiants d'outils de codage IA — Elastic et Wiz concordent sur la version d'exécution et sur la liste des identifiants ciblés par l'IA.

• Les hooks écrits dans .claude/settings.json et .vscode/tasks.json s'exécutent au démarrage de session et à l'ouverture d'un dossier, et un jeton GitHub App a étendu cela à jusqu'à 50 branches par dépôt accessible — la conclusion d'Elastic, et la base de son affirmation selon laquelle un développeur peut être infecté en ouvrant un dépôt.

• Plus de 400 paquets uniques ont été compromis en quelques jours, et la CSA Singapore, autorité de régulation nationale, a publié l'avis AD-2026-009 le 6 août 2026, répertoriant les versions concernées et les indicateurs.

Ce que les sources considèrent comme une évaluation plutôt qu’un fait doit être signalé. Wiz décrit la charge utile comme un descendant de la famille de logiciels malveillants « Mini » Shai-Hulud, construite à partir de dépôts publics Shai-Hulud-Open-Source publiés par TeamPCP, avec quelques modifications cruciales ; Orca Security attribue l’attaque à TeamPCP ; Zscaler relie ChainDrop à TeamPCP et le place dans une filiation remontant à septembre 2025. Il s’agit d’un consensus d’attribution entre fournisseurs, et non de ce qu’un document primaire cité prouve au sujet d’une personne ou d’un groupe nommé.

Trois choses qu'aucune source citée n'établit, et que cet article ne comble pas. Premièrement, comment le compte du mainteneur a été détourné : Zscaler indique clairement que le mécanisme exact était inconnu au moment de son analyse. Deuxièmement, un total final unique : les chiffres de 400, 868 et 1 300 comptent des paquets, des paquets-et-versions et des versions à des moments différents, et aucune source n'affirme que la campagne est terminée. Troisièmement, et c'est le plus important pour l'affirmation spécifique à l'IA figurant dans ce dossier, aucune source citée ne rapporte un cas confirmé où un identifiant volé d'Anthropic, Codex, Cursor, Gemini ou OpenAI aurait été rejoué contre un compte fournisseur. Ce qui est documenté, c'est l'intention et la capacité — une liste de cibles explicite, et un collecteur conçu pour l'atteindre — et non une intrusion avérée en aval dans les systèmes d'un fournisseur d'IA.

Ce qui a changé par la suite — et ce que doit faire un intervenant

La mesure corrective la plus concrète consignée est un changement de plateforme. Elastic recommande de passer à npm 12 ou une version ultérieure, qui bloque par défaut les hooks de préinstallation ; les recommandations de Microsoft préconisent, de façon indépendante, npm CLI v12 et la fonctionnalité min-release-age, qui retiennent les nouvelles versions suffisamment longtemps pour que la communauté puisse détecter une compromission avant qu’elle n’atteigne un build.

Au-delà de cela, les étapes de réponse publiées par les sources se chevauchent largement.

• Elastic : révoquez tous les jetons GitHub, y compris les jetons de session sur les machines concernées ; révoquez et régénérez les jetons npm, en particulier les jetons d’automatisation disposant de l’autorisation d’écriture et du contournement de l’authentification à deux facteurs ; recherchez dans les dépôts les commits non autorisés portant le message chore: update config from claude@users.noreply.github.com ; faites pivoter les secrets cloud, Kubernetes, Vault, des outils d’IA et CI/CD ; activez l’authentification à deux facteurs sur les comptes npm.

• Microsoft : purgez les caches npm et yarn sur les endpoints et les hôtes de build affectés, épinglez les versions réputées fiables, examinez les fichiers de verrouillage et les artefacts pour détecter les versions compromises, y compris les références transitives, reconstruisez les images de base partagées et les runners de build de référence, et examinez les portées des jetons, les approbations de workflow et la provenance des versions, car l’incident est cohérent avec un abus du pipeline CI/CD via la publication OIDC.

• CSA Singapore : retirez les versions concernées des environnements de développement, de compilation et CI/CD, considérez les systèmes concernés comme compromis et reconstruisez-les, renouvelez les identifiants, vérifiez les environnements cloud et de code source à la recherche d’accès non autorisés, surveillez les indicateurs publiés et renforcez les contrôles d’autorisation par liste, de vérification de l’intégrité et de provenance.

• Zscaler : traiter .claude/, .cursor/, .vscode/ et .gemini/ comme du code exécutable, et cesser de considérer la provenance SLSA ou Sigstore comme une preuve de sécurité — en la complétant plutôt par une détection d’anomalies sur le comportement de publication, comme les publications hors heures ouvrées, la publication de versions en masse et les éditeurs qui publient pour la première fois.

Le dossier ne contient aucun résultat de remédiation. Aucune source citée ne fait état de la suppression complète des versions malveillantes, d’une récupération de compte, d’une arrestation ou d’une mesure d’application de la réglementation ; l’avis de CSA est une notification aux défenseurs, et non un constat à l’encontre d’une partie.

Ce que l'incident modifie, c'est une classification. Un fichier de configuration d'outil de développement est un chemin d'exécution, et l'ouverture d'un dossier par un éditeur est un événement d'exécution. Et une attestation de provenance est une déclaration sur le pipeline qui a produit un paquet — et non sur qui détenait les clés lorsque ce pipeline s'est exécuté ; c'est précisément la faille dans laquelle la première version publiée de keyv est passée.