Skip to main content

Le murmure des fêtes : Shai-Hulud 3.0

Écrit par
feature insights context

29 décembre 2025

0 minutes de lecture

La période des fêtes de fin d’année est traditionnellement consacrée au gel du code et à des rotations plus calmes. C’est toutefois aussi une période privilégiée pour les attaquants opportunistes. Les acteurs malveillants apprécient les fêtes : ils savent que, les équipes de développement étant absentes et les délais de réponse naturellement plus longs, une petite fenêtre s’ouvre pour tester de nouveaux exploits sans être détectés immédiatement.

Récemment, un chercheur en sécurité a découvert une nouvelle variante circonscrite de Shai-Hulud, baptisée « The Golden Path » (v3.0). Cette version présente des améliorations techniques conçues pour déjouer les méthodes de détection actuelles. Il ne s’agit pas d’une épidémie généralisée, mais cette mise à jour technique semble témoigner des améliorations continues apportées par les acteurs malveillants.

Pour le moment, les signalements se limitent à un seul package, ce qui laisse penser qu’il pourrait s’agir d’une phase de test plutôt que d’une campagne active. Voici ce que nous savons de cette nouvelle version et pourquoi nous la surveillons de près.

Signalements de la nouvelle variante

Le 29 décembre 2025, un chercheur a identifié un malware intégré au package npm @vietmoney/react-big-calendar (version 0.26.2). Selon lui, il s’agit d’une évolution directe de la lignée Shai-Hulud plutôt que d’une imitation. L’analyse suggère que le code a été à nouveau obfusqué à partir de la source, plutôt que modifié sur place. Malgré un ADN commun, la logique interne a été affinée pour gagner en résilience et en compatibilité multiplateforme.

Les premières versions de Shai-Hulud se propageaient rapidement et privilégiaient une propagation accélérée. À l’inverse, cette variante semble désormais miser davantage sur la discrétion, en mettant l’accent sur le perfectionnement technique et la stabilité multiplateforme. Cette version fait office de « correctif » pour le malware et vise notamment à résoudre les problèmes de compatibilité antérieurs avec Windows et l’environnement d’exécution Bun.

Principaux détails techniques :

  • Exfiltration ciblée : D’après le code, les données devaient être exfiltrées vers des dépôts GitHub portant la description suivante : « Goldox-T3chs: Only Happy Girl ».

  • Améliorations de la furtivité : Le code intègre une meilleure gestion des erreurs, conçue pour contourner les outils d’analyse de sécurité.

  • Périmètre limité : Pour le moment, la compromission d’un seul package npm a été confirmée. Cela laisse penser qu’il s’agit de tester sa stabilité plutôt que de lancer immédiatement une infection à grande échelle.

Pourquoi maintenant ?

L’apparition de cette variante à ce moment précis est probablement délibérée. Les attaquants tirent parti de deux vulnérabilités majeures sans aucun lien avec le code :

  1. L’effet « vacances » : Les décideurs étant en congé et les équipes de réponse aux incidents fonctionnant en effectifs réduits, les attaquants cherchent à déployer et à perfectionner leur code avec un risque bien moindre de détection en temps réel.

  2. La transition vers de nouvelles mesures de sécurité : L’écosystème npm évolue vers la publication de paquets de confiance comme norme. Dans ce contexte, les attaquants exploitent souvent la période de « dernière minute », alors que les mesures de sécurité sont encore peu strictes, afin d’étendre leur portée avant l’entrée en vigueur de contrôles plus rigoureux. Des mises à jour ont bien été effectuées ce mois-ci, notamment le passage de npm à l’authentification par session et à la gestion des jetons CLI.

Rester vigilant, sans céder à la panique

La découverte de toute nouvelle variante mérite notre attention, mais il est essentiel de privilégier la vigilance plutôt que la panique. À ce jour, rien n’indique une campagne d’infection à grande échelle. Nous observons plutôt les mouvements encore peu visibles d’un acteur probablement sophistiqué qui prépare de futures opérations.

Notre stratégie consiste à prendre des décisions éclairées et à agir activement. Il est fort probable que l’acteur malveillant suive attentivement ces mêmes signalements et adapte son comportement, en modifiant éventuellement son calendrier de déploiement ou les signatures de ses fichiers pour échapper aux méthodes de détection actuelles. Face à un adversaire réactif, notre meilleure défense n’est pas l’alarmisme, mais une posture proactive et constante, qui part du principe que les indicateurs de compromission (IoC) évolueront.

Mesures recommandées

Plutôt que de vous fier à une analyse active recherchant des noms de fichiers précis, susceptibles de changer dès demain, nous vous recommandons de vérifier vos garde-fous structurels afin de neutraliser les principaux vecteurs d’infection de la menace. Cette approche « sécurisée par défaut » fournit une protection durable, même si l’acteur met à jour ses signatures techniques.

  • Désactivez les scripts de cycle de vie : Les principaux vecteurs d’exécution de cette souche sont les hooks postinstall et preinstall. Renforcez votre environnement en définissant ignore-scripts=true dans votre fichier .npmrc ou en lançant les installations avec l’option --ignore-scripts : cela empêche l’exécution de code arbitraire pendant l’installation.

  • Imposez les installations à partir du seul fichier de verrouillage : Dans les pipelines CI/CD, utilisez toujours npm ci au lieu de npm install. Vous garantirez ainsi que l’environnement utilise uniquement les versions exactes indiquées dans votre fichier de verrouillage, et éviterez qu’une résolution vers la version « latest » n’installe accidentellement une mise à jour compromise.

  • Prévoyez une période d’attente : Si votre gestionnaire de packages le permet, comme pnpm avec minimumReleaseAge, envisagez de différer de 24 à 48 heures l’adoption de nouvelles versions de packages. La plupart des packages npm malveillants sont repérés et supprimés dans les heures suivant leur publication.

  • Contrôlez le trafic sortant : Cette variante exfiltrant des données vers des dépôts GitHub externes, limiter l’accès réseau des serveurs de build aux seuls domaines connus et approuvés peut interrompre la chaîne d’exfiltration.

Si cette phase de test laisse présager une campagne plus vaste, ou si l’acteur fait évoluer ses techniques pour échapper aux méthodes de détection actuelles, nous publierons immédiatement une mise à jour. Pour le moment, le renforcement structurel et une surveillance continue restent nos moyens les plus efficaces.

Consultez Snyk Vulnerability Database

Des données fiables et des informations exploitables pour vous aider à développer des logiciels en toute sécurité.

Lire la suite

illustration hero ai
Blog

PHP corrige deux vulnérabilités RCE critiques exploitables sans authentification (CVE-2026-109618, CVE-2026-109619) : mettez à jour dès maintenant

Deux vulnérabilités critiques dans le cycle de traitement des requêtes de PHP peuvent permettre l’exécution de code à distance sans authentification. Passez à une version corrigée ou installez un correctif rétroporté par votre fournisseur pour les versions antérieures.

blog feature ai lilac
Blog

Transformez votre backlog de vulnérabilités en pull requests grâce à la remédiation agentique

Evo Remediation Agent est désormais disponible en aperçu ouvert et apporte la résolution automatisée des dépendances à Evo Agentic AppSec. Les équipes AppSec peuvent désormais lancer des campagnes de remédiation continues

AI Background min crop
Blog

L’IA fait surgir tous les risques que vous avez acceptés : sept enseignements du panel de sécurité de l’IA sans filtre

L’IA rend les attaques moins coûteuses et plus rapides, exposant des risques déjà présents dans les organisations. Quatre responsables de la sécurité expliquent pourquoi une défense à la vitesse des machines et une remédiation accélérée sont désormais indispensables.