Skip to main content

The Forrester Wave™ : Plateformes XDR, T2 2026

Accéder au rapport
À propos de nousPartenairesSupport technique|Connexion
Elastic logo
Démarrez un essai gratuitNous contacter

Comment gérer la faille Shai-Hulud 2.0 : la réponse actualisée d’Elastic à la compromission de la chaîne d’approvisionnement de npm

By
Mandy Andress

Qui n’aime pas les suites ? Depuis le lundi 24 novembre, la communauté des développeurs est en émoi suite à l’annonce du retour du ver Shai-Hulud et de sa mise à jour en version 2.0. La communauté est en mode réponse, et Elastic n’y fait pas exception. Bien que les produits Elastic ne soient pas fournis avec Node Package Manager (npm), notre logiciel, comme beaucoup d’autres, utilise npm pour récupérer les paquets depuis le registre npmjs.com lors des compilations.

Dans cet article, nous expliquerons les mesures prises par Elastic pour monitorer et mettre en place des actions visant à atténuer la menace que représente le nombre croissant de paquets compromis. Nous partagerons également nos règles de prévention et de détection, nos requêtes de recherche et nos recommandations conformément à cette nouvelle version de Shai-Hulud. 

Comprendre la menace évoluée : Shai-Hulud 2.0

L’immensité de l’écosystème npm en fait une cible de choix pour les activités malveillantes. En novembre 2025, une nouvelle variante du ver malveillant npm, baptisée « Shai-Hulud : The Second Coming » en raison du marqueur de campagne utilisé dans les descriptions des dépôts GitHub, a fait son apparition suite à l’attaque initiale de septembre 2025 et divulgue activement des données. Elle a compromis des centaines de paquets, dont des projets populaires d’AsyncAPI, Zapier, PostHog et Postman.

La similitude avec la variante initiale est que les paquets npm sont infectés par des logiciels malveillants auto-réplicatifs. Cependant, Shai-Hulud 2.0 diffère de sa première itération en ce qu’il installe bun avec le fichier setup_bun.js puis l’utilise pour exécuter bun_environment.js, qui contient le code malveillant. Il exfiltre ensuite les données volées en créant des dépôts GitHub nommés au hasard, publiant souvent les données d’une victime dans un dépôt associé à une victime distincte et non affiliée, appelé « exfiltration inter-victime ». Les nouveaux dépôts GitHub portent la description Sha1-Hulud : The Second Coming.

En fin de compte, cela signifie que le simple fait de rechercher dans vos propres référentiels ne révélera peut-être pas de données divulguées depuis vos environnements. De plus, Shai-Hulud ne se limite plus à infecter 20 paquets npm. Il infectera désormais jusqu’à 100 paquets npm et effacera le répertoire personnel de l’utilisateur s’il ne peut pas s’authentifier à l’aide des identifiants GitHub ou npm.

Réponse d’Elastic

Grâce aux leçons et aux mécanismes mis en œuvre à la suite de l’incident initial de Shai-Hulud, Elastic a pu déployer des défenses immédiates et complètes.

  • Inventaire des dépendances : Elastic analyse en permanence nos produits à l’aide d’outils d’analyse de la composition logicielle (SCA) qui nous ont permis de savoir rapidement quels paquets sont utilisés et où.

  • Renseignements sur les menaces : utilisation de plusieurs flux de renseignements sur les menaces pour consulter la liste croissante de packages malveillants par rapport à notre inventaire des dépendances et déclencher des alertes.

  • Bonnes pratiques et restrictions de Npmjs : depuis Shai-Hulud 1 en septembre, les équipes Elastic sont passées à Trusted Publisher, ce qui leur permet de continuer à publier ; tous les jetons restants ont été révoqués, empêchant ainsi la possibilité de publier avec un jeton à longue durée de vie.

  • Âge minimum des dépendances : Nous avons mis en place un âge minimum de publication des packages (période de refroidissement) dans notre automatisation, garantissant que les nouvelles versions des packages ne sont pas automatiquement téléchargées avant qu’elles ne soient disponibles depuis 14 jours.

  • Implémenter l’analyse des endpoints : grâce à l’intégration d’OSQuery pour Elastic Agent, nous avons implémenté une analyse continue des packages npm connus pour être compromis et installés sur les ordinateurs portables Elastic.  

  • Règles de détection prêtes à l’emploi : Elastic Security Labs fournit déjà des règles de détection Elastic Security prêtes à l’emploi pour vous aider à identifier les systèmes sur lesquels un package compromis est installé et s’exécute. Vous trouverez ci-dessous plus de détails sur les protections que vous pouvez utiliser pour votre propre recherche de menaces.

  • Prévenez les développeurs Elastic : Des avis ont été envoyés aux développeurs Elastic, les informant de l’enquête en cours et interdisant la mise à jour ou l’installation de nouveaux paquets npm.

The Second Coming frappe plus près de chez nous

Par l’intermédiaire de notre partenaire Entro, Elastic a été informée qu’un pipeline d’intégration continue (CI) d’Elastic avait fait fonctionner le malware Shai-Hulud 2.0 et publié des données sur un dépôt GitHub public. Ce pipeline est utilisé pour GitOps, et plus précisément comme orchestrateur pour Elastic Cloud. Cela n’a eu aucun impact sur les systèmes Elastic Cloud ou sur les clients d’Elastic. On a découvert que le coupable était une dépendance transitive. Notre réponse rapide et notre coordination avec nos équipes d’ingénieurs nous ont permis de contenir la menace et d’y remédier avant qu’elle ne soit exploitée.

Confinement et remédiation rapides

  • Suppression de la dépendance open source qui contenait le malware de tous les dépôts Elastic GitHub identifiés

  • Pipelines ou processus manuels identifiés sur lesquels le malware serait exécuté

  • Exécutions CI identifiées et utilisateurs concernés

  • Secrets identifiés accessibles à ces exécutions

  • Rotation de tous les secrets (non éphémères)

Aucun impact client confirmé.

  • GitHub a rapidement supprimé le référentiel qui exposait les données extraites par Elastic, qui comprenait quatre fichiers :

    • cloud.json ne contenant aucune donnée

    • contents.json contenant des détails sur un exécuteur CI ainsi qu’un utilisateur GitHub non associé et le jeton GitHub de cet utilisateur non associé

    • truffleSecrets.json contenant des détections secrètes faussement positives

    • environment.json contient des variables d’environnement associées à un coureur CI, y compris les secrets utilisés dans la compilation. Remarque : Elastic a veillé à ce que ces secrets soient révoqués.

  • Rien ne prouve que les secrets d’Elastic aient été utilisés en dehors d’Elastic.

  • Il n’y a aucune preuve que le ver se soit propagé à un paquet Elastic NPM.

  • Le pipeline n’est pas associé à un produit Elastic.

  • Il n’y a aucun impact pour les clients d’Elastic.

Requêtes de détection

Nous recommandons également aux clients d’Elastic Security de rechercher des compromis potentiels dans leur propre environnement. Les requêtes KQL suivantes peuvent être utilisées pour identifier les comportements associés à cette compromission de la chaîne d’approvisionnement :

// IOC for the Github Self-Hosted Actions runner name
process.name:Runner.Listener and process.command_line:*SHA1HULUD*

// IOC - node/bun executing bun_environment.js
process.name:(node or bun) and process.args:*bun_environment.js

// credentials discovery using trufflehog from node/bun or node_modules related working directory 
process.name:("trufflehog" or "trufflehog.exe") and process.args:"filesystem" and process.args:"--json" and (process.parent.name : (node or bun or node.exe or bun.exe) or process.working_directory:*node_modules*)

// curl used to download GH actions runner to victim machine
process.name:(curl or or curl.exe or powershell.exe or wget or wget.exe) and process.command_line:*github.com/actions/runner/releases/download*

//docker escape via mounting the host file system and executing bash commands to tamper with the host file system
process.name:docker and process.args :("--privileged" and run) and process.args :"-v" and process.args :/\:/*  and  process.args :(bash or sh or cp)

Exemples de correspondances :

Détections Elastic prêtes à l’emploi

Les règles de détection et de prévention prêtes à l’emploi suivantes fournissent également une couverture actualisée des activités liées au ver Shai-Hulud 2.0 :

Engagement envers la sécurité

La sécurité est fondamentale pour le cycle de développement et les processus opérationnels d’Elastic. Le nouveau ver Shai-Hulud souligne la nature persistante à évolution rapide des cybermenaces qui affectent les chaînes d’approvisionnement logicielles mondiales. L’incident survenu dans notre environnement démontre l’efficacité de nos équipes de sécurité et l’importance d’une réponse rapide. Nous restons engagés envers les points suivants :

  • Surveillance continue : Maintenir une surveillance 24 h/24 de nos systèmes et réseaux pour tout signe de compromission.

  • Réponse rapide : nous veillons à ce que nos équipes de sécurité soient prêtes à réagir rapidement et efficacement aux nouvelles menaces.

  • Transparence : Communiquer ouvertement avec nos utilisateurs et la communauté sur les incidents de sécurité et sur nos efforts d’atténuation.

Nous continuerons à monitorer les nouvelles informations. Et au fur et à mesure que nous en apprendrons plus sur cet événement, nous mettrons à jour cette publication. Pour plus d’informations sur la manière dont Elastic peut vous aider à sécuriser votre environnement, rendez-vous sur notre page consacrée aux solutions de sécurité.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit