Shai-Hulud ressuscite après 111 jours

Bonjour Internet,

Vous souvenez-vous de l' attaque Shai-Hulud qui a frappé @AntV le 19 mai 2026 ? Je sais, cela semble remonter à une éternité dans le monde de la supply chain. Un compte de mainteneur compromis a poussé 639 versions malveillantes de packages @antv sur npm en l'espace d'une heure. Nous avons décortiqué cette charge utile en quelques heures, aux côtés de la majeure partie de la communauté de sécurité npm. Rien de bien novateur sur le plan technique. C'était un jour comme un autre où l'on se réveille avec une attaque sur la chaîne d'approvisionnement. Du classique.

Depuis lors, npm a introduit l'analyse des logiciels malveillants au moment de la publication. Vous pouvez donc imaginer ma surprise lorsque, en parcourant notre file de triage ce matin, j'ai repéré ce que j'ai immédiatement identifié comme un petit ver. Il présentait le même hash que la @AntV vague. Même payload :

e37e3ddeeaaa9e0c4fdbcb829b4895a6521031c80053fc436625b61e6ee5b1a6. Il s'agit exactement du même fichier que npm, nous-mêmes et la moitié des éditeurs de cette liste avions déjà identifié par empreinte il y a des mois.

Cela fait 111 jours de silence radio total sur ce hash. Autant que nous puissions en juger, c'est le plus long intervalle entre la dormance et la réactivation que nous ayons observé pour un payload Shai-Hulud, et de loin. Appelez un chat un chat : c'est un zombie, qui ressurgit quatre mois après que tout le monde l'a cru mort.

Les quatre packages qui l'ont ramené, 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 notre historique de détection pour ce hachage de fichier exact à travers chaque version de paquet que nous avons analysée. Voici à quoi ressemble réellement la chronologie :

Nos registres indiquent 319 versions de paquets portant ce hachage, chacune d'entre elles ayant été détectée pour la première fois le 19 mai 2026, le jour de la @AntV vague, pas un jour avant ni un jour après. Puis plus rien. Zéro nouvelle détection sur ce hachage entre le 20 mai et le 6 septembre. Ensuite, à compter d'aujourd'hui (7 septembre), quatre nouvelles versions de paquets ont été publiées sur npm avec exactement la même charge utile. Cela représente un intervalle de 111 jours : dernière détection le 19 mai, prochaine détection le 7 septembre.

Quatre paquets, c'est un petit nombre comparé à un fait plus vaste : une charge utile dotée d'un hachage connu, publié et indexé est restée intacte dans la chaîne d'outils de personne 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 déployé l'analyse des logiciels malveillants au moment de la publication : chaque paquet est retenu pendant 5 à 15 minutes tandis qu'un système automatisé l'examine avant qu'il ne puisse être installé. Selon le journal des modifications de npm, l'objectif est d'intercepter « les logiciels malveillants que nous pouvons détecter » avant qu'ils n'atteignent npm install.

Une correspondance de hachage de fichier relève de la simple recherche, ce n'est pas un problème complexe. Cela ne nécessite aucune analyse comportementale, de mise en bac à sable ou de raisonnement sur l'intention d'un code obfusqué. De plus, cette charge utile n'était ni inédite, ni reconditionnée, ni même légèrement modifiée pour contourner la correspondance de signatures. Il s'agissait des mêmes 64 caractères hexadécimaux enregistrés depuis le mois de mai.

Nous ne prétendons pas que le scanner devrait tout attraper. Des menaces telles que les chargeurs multi-étages, la confusion de dépendances et les charges utiles déclenchées à l'exécution constituent de véritables difficultés. En revanche, une correspondance exacte de hachage avec un ver qui a fait la une des actualités internationales en matière de sécurité il y a quatre mois n'en est pas une. C'est le strict minimum de ce que l'analyse au moment de la publication est censée détecter, et cela a été manqué. Cet échantillon spécifique devrait figurer dans le corpus de test de quiconque fait de l'analyse de la chaîne d'approvisionnement.

Le point à retenir

Une charge utile de ver dotée d'un hachage public, de documentations approfondies de fournisseurs et de mois de couverture de détection est restée dormante pendant 111 jours, puis est revenue sur npm sans encombre, sur un registre qui se commercialise désormais en affirmant analyser chaque publication. Cet écart 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 intercepté constitue la véritable histoire ici. La correspondance de signatures avec des artefacts malveillants connus est le critère le plus facile à valider dans cette industrie, et c'est celui que nous devrions tous le plus nous inquiéter de voir échouer. Si c'est ce qui passe à travers les mailles du filet dans le cas le plus simple, il est permis de se demander ce qu'aurait fait 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 d'un script de pré-installation bun run index.js

Persistance :

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

Analyse comportementale :

• Appels de validation sortants vers le registre npm à l'aide de jetons volés
• Téléchargement d'archive tar, injection de charge utile, incrémentation de version, cycle de republication
• Création en masse de dépôts GitHub avec des dénominations sur le thème de Dune et des chaînes « Shai-Hulud » inversées dans les descriptions