Shai-Hulud revient d'entre les morts après 111 jours

Bonjour à tous les internautes,

Tu te souviens du Attaque de Shai-Hulud ce coup @AntV Le 19 mai 2026 ? Je sais, dans le monde de la chaîne d’approvisionnement, cela semble déjà remonter à une éternité. Un compte de responsable de maintenance piraté a publié 639 versions malveillantes de paquets @antv sur npm en l’espace d’une heure. Avec la plupart des membres de la communauté de sécurité de npm, nous avons démantelé cette charge utile en quelques heures. D'un point de vue technique, il n'y avait rien de nouveau. C'était juste une journée comme les autres : on se réveille et on découvre qu'une attaque de la chaîne d'approvisionnement a eu lieu. Comme d'habitude.

Depuis lors, npm a mis en place une analyse anti-malware au moment de la publication. Vous pouvez donc imaginer ma surprise lorsque, ce matin, en parcourant notre file d’attente de triage, j’ai repéré ce que j’ai immédiatement identifié comme un « wormy boy ». Il avait le même hachage que le @AntV wave. Même charge utile :

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Il s'agit du même fichier que npm, nous-mêmes et la moitié des fournisseurs figurant sur cette liste avions déjà identifié il y a plusieurs mois.

Cela fait 111 jours de silence total sur ce hash. À notre connaissance, c’est de loin le plus long intervalle entre la mise en veille et la réactivation jamais observé pour une charge utile Shai-Hulud. Appelons un chat un chat : c’est un « zombie » qui refait surface quatre mois après que tout le monde l’ait cru mort.

Les quatre paquets qui l'ont réintroduit, tous publiés au cours de la même heure le 7 septembre par le même compte npm :

• feishu-docx-mcp@0.3.2
• bmc-i18n-extract-cli@1.1.1
• blueai-cli@0.7.0
• bmc-translate-utils@1.1.1

Les chiffres

Nous avons extrait l'historique de détection correspondant à ce hash de fichier précis pour toutes les versions de paquets que nous avons analysées. Voici à quoi ressemble concrètement la chronologie :

D'après nos données, 319 versions de paquets portent ce hachage ; chacune d'entre elles a été observée pour la première fois le 19 mai 2026, jour du @AntV une vague, ni un jour avant ni un jour après. Puis plus rien. Aucun nouvel accès à ce hachage entre le 20 mai et le 6 septembre. Puis, à partir d’aujourd’hui (7 septembre), quatre autres versions du paquet ont été mises en ligne sur npm, contenant exactement la même charge utile. Cela représente un intervalle de 111 jours : dernière apparition le 19 mai, prochaine apparition le 7 septembre.

Quatre paquets, c'est un chiffre modeste qui met en lumière un fait plus important : une charge utile dont le hachage était connu, publié et indexé est restée inaperçue dans la chaîne d'outils de n'importe qui pendant plus de trois mois, avant d'être republiée sur un registre qui, depuis cette année, analyse explicitement chaque paquet avant sa mise en ligne.

Le cas simple

En juillet, npm a mis en place un système de détection des logiciels malveillants au moment de la publication : chaque paquet est mis en attente pendant 5 à 15 minutes, le temps qu'un système automatisé le vérifie avant qu'il ne soit disponible à l'installation. Selon le journal des modifications de npm, l'objectif est de repérer « les logiciels malveillants que nous sommes en mesure de détecter » avant qu'ils n'atteignent la commande « npm install ».

La correspondance d’un hachage de fichier est une simple recherche, et non un problème complexe. Elle ne nécessite ni « analyse comportementale », ni « sandboxing », ni même de réflexion sur l’intention derrière un code obscurci. Et cette charge utile n’était ni nouvelle, ni reconditionnée, ni même légèrement modifiée pour échapper à la détection par signature. Il s’agissait des mêmes 64 caractères hexadécimaux qui figuraient dans les fichiers depuis le mois de mai.

Nous ne disons pas que l’analyseur doit tout détecter. Les chargeurs à plusieurs étapes, la confusion des dépendances et les charges utiles déclenchées lors de l’exécution constituent des problèmes véritablement complexes. En revanche, une correspondance exacte de hachage avec un ver qui a fait la une de l’actualité internationale en matière de sécurité il y a quatre mois ne l’est pas. C’est le minimum que l’analyse au moment de la publication est censée détecter, et cela a échappé à l’analyse. Cet échantillon spécifique devrait figurer dans le corpus de test de toute personne effectuant une analyse de la chaîne d’approvisionnement.

Le point à retenir

Une charge utile de ver dotée d’un hachage public, faisant l’objet de nombreux rapports de fournisseurs et couverte par des systèmes de détection depuis des mois, est restée inactive pendant 111 jours, avant de réapparaître sans encombre sur npm, un registre qui se vante désormais d’analyser chaque publication. Ce décalage entre ce que l’analyse au niveau du registre prétend faire et ce qu’une réactivation avec un hachage identique montre qu’elle a réellement détecté constitue le véritable enjeu ici. La comparaison de signatures avec des artefacts connus pour être malveillants est l’obstacle le plus facile à franchir dans ce secteur, et c’est celui dont nous devrions tous nous inquiéter le plus lorsqu’il n’est pas surmonté. Si c’est ce qui passe dans le cas le plus simple, on est en droit de se demander ce qu’aurait pu faire une charge utile qui aurait pris la peine de modifier un seul octet.

Indicateurs de compromission

Réseau :

• t[.]m-kosche[.]com (C2, issu de la vague initiale de mai)

Fichier :

• SHA256: e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6
• Niveau racine index.js charge utile
• Exécution du script de préinstallation bun run index.js

Persévérance :

• .vscode/tasks.json
• .claude/settings.json

Comportemental :

• Appels de validation sortants vers le registre npm à l'aide de jetons volés
• Téléchargement d'un fichier tarball, injection de charge utile, mise à jour de la version, cycle de republication
• Création en masse de dépôts GitHub avec une nomenclature inspirée de l'univers de Dune et des chaînes de caractères « Shai-Hulud » inversées dans les descriptions