Quand la signature est valide et le code malveillant : l'attaque de la chaîne d'approvisionnement keyv
Le 4 août 2026, un attaquant ayant compromis le compte GitHub du mainteneur de keyv — une bibliothèque de stockage clé-valeur comptant environ 127 millions de téléchargements hebdomadaires — a poussé un voleur d’identifiants directement sur la branche principale et publié des versions sur l’ensemble de la famille de paquets. Un ver auto-propagé a ensuite utilisé les identifiants npm volés pour introduire automatiquement une porte dérobée dans chaque autre paquet sur lequel ce mainteneur avait des droits de publication. En quelques heures, la campagne avait atteint plus de 1 300 versions de paquets représentant au total deux milliards de téléchargements mensuels, dont des bibliothèques largement utilisées comme cacheable, flat-cache et file-entry-cache.
Chaque vérification cryptographique a été validée
Le détail qui devrait le plus inquiéter les équipes de sécurité n’est pas l’ampleur. Les paquets empoisonnés portaient une provenance npm valide, signée par GitHub Actions. Ils avaient bel et bien été construits dans ce dépôt, dans ce workflow, à ce commit. L’attestation était correcte. Le code était un logiciel malveillant. Il s’agit de la deuxième compromission npm en trois mois à livrer un malware avec des attestations légitimes.
La sécurité de la chaîne d’approvisionnement logicielle a, ces dernières années, convergé vers la signature et la provenance comme réponse à la falsification de paquets. Ce travail reste précieux, mais cet incident en marque clairement la limite. La provenance prouve qu’un paquet provient bien de l’endroit qu’il revendique. Elle ne dit rien sur le fait de savoir si le compte à l’origine de ce paquet était, au moment du build, sous le contrôle de son propriétaire légitime. Lorsque la compromission survient en amont du build, la signature certifie le malware.
Le payload ajoutait un script de préinstallation qui téléchargeait un environnement d’exécution et lançait un voleur d’informations obfusqué ciblant les jetons d’accès npm, les jetons GitHub CLI, les identifiants AWS, les jetons Vault, les configurations Kubernetes et les portefeuilles de cryptomonnaies. Ces identifiants volés ont ensuite servi à publier d’autres paquets compromis, ce qui a transformé une simple prise de contrôle de compte en une campagne auto-propagée.
Pourquoi cela concerne aussi les organisations qui n’écrivent aucun code
Le réflexe de la plupart des PME et sociétés de gestion d’actifs est de considérer cela comme un problème de développeurs. Ce n’est pas le cas, pour deux raisons.
D’abord, les dépendances sont transitives. Lorsqu’un développeur installe un paquet, les paquets dont ce paquet dépend sont installés automatiquement. Des composants que personne n’a choisis se retrouvent dans le build — c’est précisément pourquoi la compromission d’une seule bibliothèque de cache s’est propagée dans les chaînes d’approvisionnement logicielles de nombreuses organisations qui n’en avaient jamais entendu parler.
Ensuite, et c’est plus pertinent si vous achetez plutôt que vous ne développez : vos fournisseurs portent cette exposition. Le portail client, le système de réservation, l’outil interne développé par une agence il y a deux ans — tout cela dépend probablement de paquets npm. Un voleur d’identifiants s’exécutant dans l’environnement CI d’un fournisseur atteint les identifiants cloud et les jetons de déploiement des systèmes qui hébergent vos données. Votre questionnaire de risque tiers ne pose presque certainement pas cette question.
Que faire
Si vous développez des logiciels, l’action immédiate consiste à déterminer si une version affectée a été retirée et, surtout, si elle a pu s’exécuter. Les versions malveillantes ont été publiées dans une fenêtre délimitée le 4 août ; une version antérieure à cette fenêtre ne fait pas partie de la campagne — vérifiez donc la version précise plutôt que le seul nom du paquet. Lorsque les scripts de cycle de vie sont désactivés par défaut, un paquet retiré mais jamais exécuté représente un risque nettement plus faible. En cas d’exécution confirmée, renouveler les jetons d’accès npm, les identifiants cloud et tout secret accessible depuis cet environnement, et examinez l’activité de publication récente de vos propres paquets.
Sur le plan structurel, la leçon est que les décisions de confiance ne peuvent reposer sur les seules signatures. Fixez vos dépendances à des versions exactes plutôt qu’à des plages, désactivez par défaut les scripts d’installation dans les environnements de développement comme en CI, et observez une période de mise en attente pour les nouvelles versions avant qu’elles n’atteignent vos builds. L’essentiel des dégâts dans ce type de campagne survient dans les premières heures suivant la publication — même un court délai élimine l’essentiel de l’exposition.
Pour les organisations qui achètent plutôt qu’elles ne développent, cela doit désormais figurer dans votre processus d’assurance fournisseurs : demandez-leur s’ils ont été touchés par la campagne npm du 4 août, comment ils déterminent quels composants open source entrent dans leurs produits, et quel est leur processus de rotation des identifiants après une suspicion de compromission de leur système de build. Une réassurance vague n’est pas une réponse.
Message clé : Un compte de mainteneur compromis a transformé des centaines de paquets npm de confiance en voleurs d’identifiants, et les versions malveillantes portaient une provenance cryptographiquement valide. La signature prouve l’origine, pas l’intégrité de l’intention, et ne peut constituer la seule base de confiance envers une dépendance. Vérifiez les versions précises plutôt que les noms de paquets, désactivez les scripts d’installation, différez l’adoption des nouvelles versions, et étendez cette question aux fournisseurs qui développent des logiciels pour votre compte.
