Connexion Premium

Plus de 1 300 paquets contaminés dans NPM : Shai-Hulud « de retour » avec ChainDrop

Revoilà la sous-préfète

Plus de 1 300 paquets contaminés dans NPM : Shai-Hulud « de retour » avec ChainDrop

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.

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.

Cadenas en colère - Contenu premium

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

Commentaires (3)

votre avatar
Et on en revient toujours à "Il faut que le code soit testé par un tiers".

Au pire de le faire sur des moteurs de test qui permettent (comme le fait Google avec les applications mobile) de :

  • 1 voir s'il reconnait du code malveillant déjà estampillé malveillant. Un attaquant cherche lui aussi à optimiser son temps et va reprendre des éléments A ou B.

  • 2 Faire tourner sur une Sandbox et regarder ce que cela fait. Ca permet de détecter des accès sensibles ou hors contexte de l'application (ou module).



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 ?
votre avatar
Peut-êtrr parce que NPM n'a pas les moyens de Google.
votre avatar
C'est là qu'on se dit que tout ce système de dépendance de packages (qui ne concerne pas que NPM bien entendu) est peut-être une bonne idée sur le papier, mais dans la pratique, ça a fini par engendre des attaques de supply chain tellement chiantes entre les dépendances vérolées et les dépendances de dépendances transitives vérolées...

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é.