Quand le ver Shai‑Hulud devient public : l’effet domino des malwares npm

Les participants seraient évalués notamment selon le nombre de téléchargements des paquets compromis. Ce système incite logiquement les attaquants à viser des bibliothèques populaires ou des arbres de dépendances très utilisés afin d’augmenter l’impact de leur attaque.

Pour de nombreux chercheurs, ce concours revient à gamifier les attaques de chaîne d’approvisionnement : plusieurs acteurs peuvent désormais lancer des campagnes simultanément avec le même outil.

Des paquets malveillants copiés apparaissent sur npm

Peu après la publication du code, plusieurs paquets suspects ont été repérés sur npm. Une enquête a notamment identifié quatre paquets malveillants :

• chalk-tempalte
• @deadcode09284814/axios-util
• axois-utils
• color-style-utils

Au moins l’un d’entre eux contenait un clone non obfusqué de Shai‑Hulud, tandis que d’autres embarquaient des voleurs d’identifiants ou des fonctions de botnet.

La rapidité avec laquelle ces paquets sont apparus montre à quelle vitesse un malware open source peut se diffuser lorsque son code devient public.

Le rôle clé du typosquatting

La plupart de ces paquets malveillants utilisent une technique bien connue : le typosquatting.

Les attaquants publient des bibliothèques dont le nom ressemble fortement à celui d’un paquet légitime. L’objectif est simple : profiter d’une faute de frappe ou d’un manque d’attention lors de l’installation.

Quelques exemples observés dans cette campagne :

• chalk-tempalte, qui imite la structure de chalk-template
• axois-utils, qui ressemble à des utilitaires liés à axios

Comme les installations npm sont souvent exécutées automatiquement dans des pipelines CI/CD ou via des dépendances transitives, une simple faute peut suffire pour exécuter du code malveillant pendant l’installation.

Ce que peut faire le malware Shai‑Hulud

Shai‑Hulud n’est pas un simple paquet malveillant : il se comporte comme un ver de chaîne d’approvisionnement auto‑propagateur.

Les analyses de sécurité ont identifié plusieurs capacités importantes :

• vol d’identifiants depuis les environnements de développement et les runners CI/CD
• récupération de jetons cloud (AWS, GCP, Azure)
• exfiltration de secrets vers des dépôts GitHub contrôlés par les attaquants
• compromission d’autres paquets npm lorsque des jetons de publication de mainteneur sont découverts

Dans certaines attaques précédentes, le malware pouvait automatiquement publier des versions infectées de tous les paquets accessibles avec un jeton volé, ce qui lui permettait de se propager dans l’écosystème sans serveur de commande centralisé.

Pourquoi cette affaire marque une escalade majeure

Shai‑Hulud était déjà notable pour son comportement de ver et pour sa cible principale : l’infrastructure des développeurs plutôt que les utilisateurs finaux.

Deux évolutions ont toutefois changé la nature du risque.

1. L’ouverture du code de l’attaque

La publication du code transforme Shai‑Hulud en kit d’attaque réutilisable, accessible à de nombreux acteurs malveillants.

2. L’incitation financière via un concours

Le concours organisé autour de l’outil crée un système d’incitations directes qui encourage l’expérimentation et les attaques copiées.

Résultat : la menace ne vient plus d’un seul groupe organisé, mais potentiellement de nombreux acteurs indépendants utilisant le même framework.

Une leçon pour tout l’écosystème open source

L’affaire Shai‑Hulud illustre une tendance de fond dans la cybersécurité : les attaquants ciblent désormais la chaîne de fabrication du logiciel elle‑même.

Les registres de paquets, les pipelines CI/CD, les workflows de publication et les identifiants des mainteneurs deviennent des points d’entrée privilégiés. Une fois qu’un paquet malveillant s’insère dans cette chaîne, il peut s’exécuter lors de l’installation, voler des secrets dans les systèmes de build et compromettre potentiellement tous les projets dépendants.

La vague de paquets copiés apparue après la publication du code Shai‑Hulud montre qu’une seule attaque de chaîne d’approvisionnement peut rapidement se transformer en écosystème entier de malwares lorsque les outils deviennent publics.

Pour les équipes de sécurité, la conclusion est claire : protéger une application ne suffit plus. Il faut désormais sécuriser toute la chaîne de développement qui la produit.