Plus de 1 300 paquets contaminés dans NPM : Shai-Hulud « de retour » avec ChainDrop
Revoilà la sous-préfète
Le 05 août à 17h40
Un « nouveau » malware s’est propagé dans des centaines de paquets sur npm, dont plusieurs très populaires. Il s’agit une nouvelle fois d’une attaque contre la chaine d’approvisionnement ayant réussi à contourner toutes les mesures de sécurité. Dans le code, l’ombre de Shai-Hulud plane, tandis que le point de défaillance initial n’est pas clair.
Plus de 1 300 paquets contaminés dans NPM : Shai-Hulud « de retour » avec ChainDrop
Revoilà la sous-préfète
Un « nouveau » malware s’est propagé dans des centaines de paquets sur npm, dont plusieurs très populaires. Il s’agit une nouvelle fois d’une attaque contre la chaine d’approvisionnement ayant réussi à contourner toutes les mesures de sécurité. Dans le code, l’ombre de Shai-Hulud plane, tandis que le point de défaillance initial n’est pas clair.
Sécurité
Sécurité
9 min
Le nouveau venu se nomme ChainDrop. Selon les analyses faites sur son code, il est basé sur Shai-Hulud (en référence au ver des sables dans l’univers de Dune), qui avait déjà fait un carnage dans NPM en septembre 2025. Il en reprend les principales caractéristiques, dont son aspect auto-répliquant et le vol de nombreuses informations.
On pourrait croire que l’attaque de l’automne 2025 avait provoqué une vague d’actions pour verrouiller les comptes et inciter à la plus extrême prudence. C’est en fait le cas, mais le ou les pirates s’y sont pris autrement.
Que s’est-il passé ?
La compromission a été réalisée en poussant directement des fichiers malveillants sur la branche principale des dépôts, puis en créant immédiatement de nouvelles versions. Conséquence, ces versions vérolées ont été publiées sur NPM avec une provenance valide signée par GitHub Actions. Les contrôles de provenance npm, censés garantir qu’un package provient bien d’un flux légitime, n’ont ainsi rien pu détecter car les pirates ont justement réussi à le détourner.
868 paquets, répartis sur 1 381 versions, ont pu être contaminés par ce biais. Le pouvoir de nuisance est réel, car beaucoup d’entre eux sont populaires, l’ensemble de la liste cumulant en moyenne deux milliards de téléchargements par mois.
Tout est parti de la compromission du compte du mainteneur du paquet keyv (Jared Wray), qui représente à lui seul plus de 600 millions de téléchargements par mois. S’en sont suivies les contaminations de flat-cache, file-entry-cache, cacheable-request, cacheable ou encore cache-manager, autant de projets spécialisés dans la gestion des caches pour de multiples cas de figure.
Une fois les paquets contaminés, la propagation s’est faite rapidement, atteignant des entreprises comme Deliveroo, Ornikar, OneReach, Picsart, Qlik ou ServiceTitan.
La petite chimie de ChainDrop
Les chercheurs de l’entreprise de sécurité Aikido se sont penchés sur ChainDrop. Dans leur billet publié le 4 aout, ils décrivent ainsi deux composants retrouvés dans les paquets contaminés, comme c’est souvent le cas.
Le premier est un dropper nommé setup.mjs. Un dropper est un code chargé d’installer un ou plusieurs composants malveillants sur le système. Il sert de vecteur d’installation pour la charge utile (payload) et remplit plusieurs missions : déposer l’exécutable sur le disque, l’extraire depuis des données intégrées dans le programme ou le télécharger depuis un serveur distant, l’exécuter en mémoire ou encore mettre en place des mécanismes de persistance avant de lancer la charge utile. Selon les chercheurs, setup.mjs est un dropper fortement obfusqué récupérant le runtime JavaScript Bun depuis son dépôt GitHub pour pouvoir exécuter ensuite la charge.
Il reste 66% de l'article à découvrir.
Déjà abonné ou lecteur ? Se connecter
Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.
Accédez en illimité aux articles
Profitez d'un média expert et unique
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
expert et sans pub.
Commentaires (3)
Il y a 20 minutes
Au pire de le faire sur des moteurs de test qui permettent (comme le fait Google avec les applications mobile) de :
Pour rappel Google le fait déjà. Mais ce n'est pas le seul exemple. Dans la sécu aussi il y a des outils etc.
Pour Google cela va même assez loin. Ça inspecte aussi d'autres choses. Comme l'accessibilité pour les malvoyants et plein d'autres.
Pourquoi NPM ne pourrait pas le faire ?
On a l'impression scandales après scandales qu'on a une autruche aux commandes. Peut on encore faire confiance à ce genre de structure ?
À l'instant
Modifié il y a 14 minutes
Je pense que l'idée de base n'est pas bonne à jeter, mais peut être que ces tonnes d'interdépendances pour une fonctionnalité engendrent plus de complexité et d'emmerdes que de recoder la-dite fonctionnalité.
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?