Sommaire
Un ver auto-propagé nommé ChainDrop a infecté plus de 400 paquets npm, dont keyv, flat-cache et cache-manager, a signalé Microsoft le 4 août 2026. Le logiciel malveillant vole des identifiants de développeurs et de cloud, puis piège d'autres paquets de lui-même. Pour les équipes de risque tiers, c'est une exposition de quatrième partie que les registres fournisseurs ne captent jamais.
Un ver auto-propagé a infecté plus de 400 paquets npm, les briques logicielles partagées présentes dans des millions de projets JavaScript. Microsoft Threat Intelligence, qui a nommé la campagne ChainDrop, a signalé le 4 août 2026 que le logiciel malveillant vole les identifiants des développeurs et du cloud, puis utilise ces clés volées pour publier de lui-même des versions piégées d'autres paquets. Le code affecté comprend des utilitaires très répandus comme keyv, flat-cache et cache-manager. Toute organisation dont les développeurs ou les systèmes de build ont installé une version malveillante peut avoir laissé fuir des identifiants npm, GitHub, cloud et de coffres à secrets. La leçon : une seule dépendance open source, compromise à la source, peut atteindre tous les secrets en aval.
Ce qui s'est passé
Microsoft a publié son analyse le 4 août 2026 et l'a mise à jour le 5 août. L'éditeur attribue la compromission initiale à des identifiants de mainteneur volés, et non à une faille de npm lui-même (npm est le principal registre du code JavaScript). Les versions malveillantes embarquent une variante du ver Shai-Hulud, livrée sous la forme d'une charge volumineuse et fortement obscurcie qui s'exécute via un hook preinstall de npm, c'est-à-dire qu'elle se déclenche automatiquement avant la fin de l'installation. Une fois active, elle recherche sur les postes de développeurs et les systèmes d'intégration continue des identifiants npm, GitHub, Amazon Web Services, Kubernetes et HashiCorp Vault (Vault est un coffre à secrets courant). Elle valide les clés volées auprès de chaque service, récolte d'autres secrets et chiffre les résultats vers un serveur contrôlé par l'attaquant. La caractéristique première du ver est sa propagation automatique : avec un jeton de publication npm volé, il télécharge la dernière version d'un paquet, s'y insère, incrémente le numéro de correctif et republie, transformant un seul compte compromis en de nombreuses versions piégées. Certains paquets ont été republiés via des workflows GitHub Actions de type trusted publisher, de sorte que les versions falsifiées portaient des signatures de provenance valides. Des sociétés de sécurité, dont Aikido, ont recensé au moins 444 paquets répartis sur plus de 1 300 versions ; Microsoft en confirme plus de 400. Les utilitaires touchés figurent parmi les plus installés de l'écosystème JavaScript, avec des téléchargements rapportés se comptant en milliards d'installations par mois sur l'ensemble de la famille.
Pourquoi c'est important pour le risque tiers
C'est le risque de chaîne logicielle TIC à l'état brut : une exposition de quatrième partie que la plupart des registres fournisseurs ne recensent jamais. Votre fournisseur n'avait pas besoin d'être piraté. Un paquet situé trois ou quatre niveaux de dépendances plus loin, dans un produit que vous avez acheté ou construit, a suffi. Deux caractéristiques rendent ChainDrop pire qu'un détournement isolé. Il se propage seul, si bien que la liste des paquets touchés grossissait d'heure en heure au lieu de rester figée. Et il a produit des versions dotées d'une provenance valide, la preuve cryptographique qu'un paquet provient d'un pipeline légitime, ce qui sape un contrôle que beaucoup d'équipes prennent pour un feu vert. La concentration est le risque discret ici : quelques mainteneurs possèdent des utilitaires présents dans une très large part de l'écosystème JavaScript, de sorte que la prise de contrôle d'un seul compte porte loin.
Ce que les équipes doivent en retenir
Traitez votre arbre de dépendances, y compris les dépendances transitives, comme une partie de votre parc de fournisseurs et inventoriez-le en conséquence. Épinglez des versions connues comme saines, différez l'adoption des toutes nouvelles versions (le paramètre min-release-age de npm y aide) et désactivez les scripts d'installation lorsque c'est possible. Si un build ou un poste a récupéré une version affectée, renouvelez tous les identifiants qu'il pouvait atteindre depuis une machine saine, et non depuis la machine infectée, et vérifiez les caches d'intégration continue et les images de build partagées, qui peuvent transporter silencieusement les fichiers piégés. Ne considérez pas une signature de provenance valide comme une preuve de sûreté cette semaine.
Pour les équipes qui cherchent à déterminer lesquelles de leurs dépendances logicielles et de leurs fournisseurs pourraient porter ce type de risque de quatrième partie, découvrez comment fonctionne la surveillance continue des fournisseurs et des dépendances.
FAQ
Qu'est-ce que ChainDrop ?
ChainDrop est le nom donné par Microsoft Threat Intelligence à une attaque de grande ampleur sur la chaîne logicielle npm, révélée le 4 août 2026. Un ver auto-propagé, une variante du logiciel malveillant Shai-Hulud, a infecté plus de 400 paquets JavaScript, volé des identifiants de développeurs et de cloud, et utilisé des jetons de publication volés pour se propager automatiquement à d'autres paquets.
Comment savoir si mon organisation est touchée ?
Examinez les arbres de dépendances, les fichiers de verrouillage (lockfiles), les dépôts d'artefacts et les caches d'intégration continue à la recherche des versions de paquets affectées, y compris les références transitives que vous n'avez pas ajoutées directement. Microsoft a publié des empreintes (hashes) de paquets et des indicateurs de compromission. Tout poste ou runner de build ayant installé une version malveillante doit être considéré comme potentiellement compromis, et ses identifiants accessibles doivent être renouvelés depuis un hôte sain.
Une signature de provenance valide garantit-elle qu'un paquet est sûr ?
Pas dans ce cas. Certaines versions piégées ont été republiées via des workflows GitHub Actions de type trusted publisher, et portaient donc une provenance valide. La provenance indique où une version a été construite, pas que son contenu est digne de confiance. Épinglez des versions connues comme saines et vérifiez-les par rapport aux indicateurs publiés, plutôt que de vous fier à la seule signature.
Vous souhaitez appliquer cela à votre écosystème fournisseurs ? Découvrez la plateforme en action et cartographiez vos principaux risques fournisseurs en direct lors d'une présentation.
