Attaque de la chaîne d'approvisionnement Mini Shai-Hulud : pourquoi cette campagne change la façon dont les défenseurs devraient penser aux logiciels de confiance

L'attaque de la chaîne logistique « Mini Shai-Hulud » n'est pas simplement un incident de plus lié à un paquet malveillant. Cette campagne a exploité de manière abusive des infrastructures de publication légitimes, notamment des workflows de publication fiables, des pipelines signés par provenance et des environnements de développement. Ces techniques permettent notamment de faire passer des activités malveillantes pour des activités normales, car le code passe la plupart des contrôles de vérification et d'intégrité standard.

Selon l'analyse rétrospective de TanStack publiée par l' , les paquets TanStack compromis comportaient des attestations de provenance valides, générées par le pipeline de publication fiable de GitHub Actions propre au projet. Même lorsque les attestations de provenance étaient valides, la provenance à elle seule ne suffisait pas. La campagne, attribuée au groupe malveillant TeamPCP, a ensuite utilisé les identifiants de publication volés pour étendre la campagne à d'autres paquets.

Bon nombre des mesures de contrôle que les équipes de sécurité ont mis en place au fil des années ont été conçues pour vérifier l'authenticité, et non l'intention. Dans le cadre de cette campagne, les contrôles d'authenticité auraient toujours été validés alors même que le logiciel fourni était compromis.

Que s'est-il passé lors de l'attaque de la chaîne d'approvisionnement « Mini Shai-Hulud » ?

Comme cela a été largement rapporté au sein de la communauté de la sécurité, cette campagne a touché plus de 170 paquets sur npm et PyPI et a eu des répercussions sur des écosystèmes ayant une portée en aval considérable. Cette attaque visait des outils et des bibliothèques de développement largement utilisés, notamment des paquets liés à des frameworks front-end, des SDK d'IA, des outils d'automatisation d'entreprise et des infrastructures de recherche.

Dans les grandes lignes, la campagne s'est déroulée comme suit :

• Les pirates ont détourné une chaîne de publication fiable en compromettant le processus de compilation lui-même.
• Des versions malveillantes de paquets ont été publiées via des processus légitimes et étaient accompagnées d'attestations de provenance valides.
• Une fois installés, ces paquets volaient les identifiants sur les machines des développeurs et les serveurs CI/CD.
• Le logiciel malveillant a ensuite utilisé ces identifiants volés pour publier d'autres paquets corrompus.
• Des mécanismes de persistance ont été mis en place afin de résister aux tentatives de nettoyage et de poursuivre le vol d'identifiants.

C'est ce qui a donné à cette campagne son caractère viral. Chaque environnement nouvellement compromis pourrait devenir un point de diffusion pour la prochaine vague.

En quoi cette attaque est-elle différente ?

Il a détourné les processus de publication sécurisés, et pas seulement la confiance accordée aux paquets

L'attaquant a détourné un pipeline de publication légitime, plutôt que de se contenter de publier des typosquats évidents ou de faux paquets. Les versions malveillantes conservaient des signaux de provenance valides, ce qui montre que les contrôles d'authenticité à eux seuls n'étaient pas suffisants.

Si votre seul critère de contrôle, ou votre critère principal, consiste à vérifier si un paquet provient bien du pipeline prévu, cela n'est pas suffisant. Le pipeline constituait le vecteur d'attaque, et le Mini Shai-Hulud apparaissait comme légitime lors des contrôles habituels visant à vérifier et à confirmer quel pipeline avait généré un artefact, et non à déterminer si le contenu de cet artefact était intentionnel.

Cela s'est propagé par le biais de l'identité, et pas seulement par le code

Cette campagne était fortement axée sur l'identité et s'inscrivait dans un écosystème caractérisé par une prolifération extrême des secrets. L'ampleur des secrets exposés au sein de l'écosystème lui a permis de prendre de l'ampleur : GitGuardian a signalé que 28,65 millions de nouveaux secrets codés en dur avaient été exposés publiquement sur GitHub en 2025.

Plutôt que de se contenter d'une exécution ponctuelle, elle s'est attachée à dérober des identifiants sur les machines des développeurs et les environnements CI/CD. Une fois que les pirates disposaient de ces identités, la publication des logiciels elle-même est devenue le vecteur de propagation. Il visait les environnements de développement en tant que couche de persistance.

Dans le cadre de cette campagne, des mécanismes de persistance ont été intégrés aux outils de développement et aux chemins de configuration locaux, notamment , aux répertoires liés aux IDE et aux environnements de codage assistés par IA. La persistance dans le fichier .claude/settings.json (un hook SessionStart qui se réexécute à chaque session de Claude Code) et dans le fichier .vscode/tasks.json (exécution automatique à l'ouverture du dossier) signifie que le simple fait d'exécuter « npm uninstall » ne suffit pas à le supprimer.

Comment s'est déroulée la chaîne d'attaque ?

Bien que les modalités d’exécution aient varié selon les suites logicielles et les écosystèmes, la campagne combinait globalement l’ la compromission de la chaîne d’approvisionnement, le vol d’identifiants et l’auto-propagation.

Ce que le logiciel malveillant a tenté de voler

Les informations relatives à l'attaque de la chaîne d'approvisionnement « Mini Shai-Hulud » indiquent une portée très étendue. L'objectif ne se limitait pas à un seul type de jeton. En Q3 2025, Sonatype a constaté que 37 % des paquets open source malveillants visaient l'exfiltration de données, et cette campagne suivait ce même schéma. Il a été conçu pour recueillir tout élément utile au déplacement latéral, à la persistance et à la poursuite de la compromission.

Parmi les cibles courantes, on comptait :

• Identifiants du fournisseur de services cloud
• Jetons du registre des paquets
• Les secrets du pipeline CI/CD
• Identifiants Git et jetons de contrôle de version
• Les fichiers de configuration Kubernetes, les jetons de compte de service, ainsi que les identifiants ou jetons permettant d'accéder aux gestionnaires de secrets
• Clés SSH
• Fichiers de configuration du développeur local
• Paramètres des outils de développement IA
• Données relatives aux portefeuilles de cryptomonnaies dans certaines variantes

Les équipes d'intervention ne doivent pas se contenter de « changer le jeton npm et passer à autre chose ». Si un paquet malveillant venait à s'exécuter dans un environnement sensible, le rayon d'action serait probablement bien plus étendu.

Signes indiquant que vous pourriez être concerné(e)

Les équipes de sécurité chargées d'enquêter sur une éventuelle faille de sécurité doivent examiner à la fois les dépendances et le comportement des terminaux. Il ne s'agit pas uniquement d'un problème lié à la composition des logiciels.

Signes au niveau de la dépendance

Commencez par :

• Fichiers de verrouillage faisant référence aux versions concernées
• Journaux d'installation des paquets à partir de la version « 11 mai »
• Scripts de cycle de vie imprévus, tels que « preinstall » ou « prepare »
• Dépendances facultatives suspectes ou références à des paquets basées sur Git
• Fichiers tar d'une taille inhabituellement importante ou contenant des fichiers obscurcis

Signes au niveau des terminaux et de l'environnement

Recherchez également :

• Modifications inattendues dans les répertoires .vscode/, , .claude/ ou
• Agents de démarrage non autorisés ou services systemd au niveau utilisateur
• De nouveaux fichiers de workflow ont été ajoutés aux référentiels
• Connexions sortantes vers des infrastructures suspectes lors de l'installation d'un paquet
• Événements de publication de paquets que les responsables ne reconnaissent pas
• Dépôts publics suspects ou commits créés à l'aide d'identifiants volés

Signes liés au réseau et au comportement

Les principaux rapports d'incidents mettent également en évidence l'existence de canaux d'exfiltration redondants. Cela signifie que les responsables de la sécurité ne doivent pas partir du principe que le fait de bloquer un domaine élimine le risque. À surveiller :

• Appels API inhabituels vers des plateformes d'hébergement de code
• Le trafic vers des domaines connus pour être contrôlés par des attaquants, des API publiques d'hébergement de code utilisées à des fins d'exfiltration, des points de terminaison Webhook, des infrastructures liées à Tor ou des passerelles IPFS, si celles-ci ont été observées
• Accès soudain aux services de métadonnées, aux coffres-forts locaux ou aux magasins de jetons
• Comportement d'un processus qui lit les variables d'environnement, les magasins de jetons, l'historique du shell, les identifiants du gestionnaire de paquets ou d'autres fichiers contenant des informations confidentielles sur les postes de travail des développeurs et les machines d'exécution CI

Comment réagir face à l'attaque de la chaîne d'approvisionnement « Mini Shai-Hulud »

Il s'agit d'un incident qui nécessite une coordination entre les services de sécurité et les opérations informatiques. Une réponse efficace suit généralement un déroulement précis.

Mesures immédiates

• Vérifiez si les versions concernées des paquets ont été installées.
• Isolez les postes de travail des développeurs et les environnements CI/CD concernés avant de révoquer les identifiants.
• Assurez-vous de vous coordonner avec le service IR afin que la révocation des jetons ne déclenche pas de logique destructive connue sur les hôtes encore connectés.
• Recherchez les artefacts de persistance avant d'apporter des modifications de grande envergure.
• Conservez les éléments de preuve médico-légaux dans la mesure du possible.
• Vérifiez si des paquets relevant de votre responsabilité ont été republiés de manière inattendue.

Pourquoi le séquençage est-il important ?

Ce logiciel malveillant intègre un dispositif de sécurité d'urgence. Un démon de persistance (gh-token-monitor) interroge GitHub toutes les 60 secondes. Lorsqu'il détecte la révocation d'un jeton (réponse HTTP 40X ), il exécute la commande « rm -rf ~/ » — un effacement complet du répertoire personnel. Cela signifie que les responsables de la sécurité doivent isoler les environnements compromis avant de révoquer les identifiants. Si vous procédez dans le mauvais ordre, cela déclenche la charge destructive. C'est pourquoi une réaction mesurée ne consiste pas simplement à « tout révoquer immédiatement ». C'est :

• Commencez par isoler
• Vérifier la persistance
• Image (si nécessaire)
• Ensuite, effectuez la rotation et la remise en état selon une séquence contrôlée

Les équipes qui ont investi dans des solutions de réponse aux incidents de type « » et dans des opérations de sécurité sont mieux à même de coordonner cette séquence entre les terminaux, les identités et les processus d'analyse forensic.

Ce que cet incident révèle sur la confiance dans les logiciels

L'attaque de la chaîne d'approvisionnement « Mini Shai-Hulud » met en évidence un angle mort dont souffrent encore de nombreuses organisations : elles assimilent les éléments signés, officiels ou dont la provenance est vérifiée à la sécurité.

Ces signaux restent néanmoins précieux. Mais elles ne suffisent pas à elles seules.

Un modèle plus complet comprend désormais tous les éléments suivants :

• Vérifier la provenance d'un logiciel
• Retarder l'adoption des versions récemment publiées
• Restriction de l'exécution des scripts lors de l'installation
• Suivi du comportement d'exécution pendant les compilations et les installations
• Réduire l'exposition des secrets dans le cadre du CI/CD
• Surveiller les points de terminaison des développeurs avec la même rigueur que celle appliquée aux serveurs

Mesures concrètes de renforcement de la sécurité que les équipes devraient mettre en œuvre dès maintenant

La bonne réponse à long terme ne consiste pas à éviter les mesures de relance sous l'effet de la panique. Il s'agit d'un durcissement par couches.

Contrôles de compilation et d'empaquetage

Ces éléments s'inscrivent tous dans le cadre d'une stratégie plus large de défense de la chaîne d'approvisionnement logicielle de l' , disponible à l'adresse , qui part du principe que même les flux de travail fiables peuvent faire l'objet d'abus.

Contrôles relatifs à l'identité et aux secrets

• Réduire la durée de validité des identifiants de publication à longue durée de vie
• Définir rigoureusement les identités CI/CD
• Autorisations distinctes pour la compilation, la publication et le déploiement
• Réduire au minimum les secrets présents sur les nœuds exécutants
• Vérifiez régulièrement les paramètres d'accès à la publication des paquets et ceux permettant de contourner l'authentification à deux facteurs

Contrôles des terminaux et de l'environnement de développement

• Surveiller les chemins de configuration IDE et les hooks de démarrage
• Considérez les répertoires des outils de développement comme présentant un risque pour la sécurité, et non comme inoffensifs
• Inventaire dans lequel sont stockés les identifiants de connexion au cloud et les jetons de registre
• Vérifiez que les données persistantes ont bien été supprimées, et pas seulement que le paquet a été supprimé

Ce qu'exige une réponse efficace en matière de chaîne d'approvisionnement

Il ne s'agit pas uniquement d'un problème de vulnérabilité lié à un logiciel. Il s'agit à la fois d'un problème lié aux terminaux, à l'identité et à la réponse opérationnelle.

En résumé : si des développeurs ou des systèmes de compilation automatisés de votre organisation ont installé des composants concernés depuis le 11 mai, considérez ces environnements comme compromis. La propagation reposant sur des identités volées, chaque environnement compromis pouvait devenir un point de diffusion.

Il s'agit du premier cas documenté d'une attaque de la chaîne d'approvisionnement à propagation autonome ayant généré des paquets malveillants accompagnés d'attestations de provenance valides et conformes aux normes du secteur. Le modèle « Supply-chain Levels for Software Artifacts » (SLSA) a fonctionné conformément à sa conception. L'écosystème pensait avoir résolu davantage de problèmes qu'il n'en résout réellement. La provenance permet de déterminer quel pipeline a généré un artefact, mais pas si ce pipeline fonctionnait comme prévu.

L'agresseur n'a pas falsifié de faux reçu. Ils se sont introduits dans la cuisine et ont préparé un repas empoisonné en utilisant la cuisinière du restaurant. Le ticket de caisse était exact d'un point de vue technique.

Le groupe TeamPCP (également connu sous les noms de DeadCatx3, PCPcat, ShellForce et CipherForce) a systématiquement pris pour cible la chaîne de confiance elle-même :

• Mars 2026 : Trivy, un scanner de sécurité open source — les outils utilisés par les responsables de la sécurité (Microsoft)
• Avril 2026 : Bitwarden CLI, un gestionnaire de mots de passe — stockage des identifiants
• N° 2026 de mai : le ver de l'écosystème npm/PyPI — la chaîne d'approvisionnement logicielle au sens large

Le groupe a annoncé un partenariat avec Vect, une opération de « ransomware-as-a-service » (Unit 42). Les indicateurs d'attribution comprennent un « kill switch » spécifique à la version russe (Microsoft). Qu'il s'agisse d'un seul opérateur ou de plusieurs affiliés, cette tendance semble indiquer que les outils d'attaque visant la chaîne d'approvisionnement gagnent en sophistication au sein des réseaux liés aux ransomwares.

Les attaques visant la chaîne d'approvisionnement constituent souvent les prémices d'attaques plus importantes, notamment des attaques par ransomware, plutôt que de simples cas isolés de vol d'identifiants. Les récentes campagnes exploitant des marques de logiciels de confiance telles que Notepad++ et les canaux de téléchargement confirment que les canaux de distribution de logiciels restent des cibles de premier ordre.

Pour les défenseurs, cela se décompose en trois phases, avec leurs délais respectifs :

1. Actions immédiates à traiter en priorité (en heures)

• Vérifiez les fichiers de verrouillage et les journaux CI afin de repérer les versions de paquets concernées installées depuis 11 mai
• Si l'exposition est confirmée, isolez l'environnement avant de révoquer les jetons
• Recherchez les noms de fichiers connus pour leur persistance, tels que : , com.user.gh-token-monitor.plist, , , gh-token-monitor.service et. Recherchez également les LaunchAgents non autorisés fonctionnellement équivalents, les services utilisateur, les tâches cron, les modifications apportées au démarrage du shell et les hooks de démarrage des IDE ou des outils.
• Vérifiez les répertoires .claude/ et .vscode/ pour détecter d'éventuelles charges utiles de persistance injectées
• Renouvelez tous les identifiants accessibles depuis n'importe quel environnement exposé, et pas seulement les jetons npm

2. Mesures à court terme (en jours)

• Vérifiez les manifestes de dépendances, les fichiers de verrouillage, les journaux d'intégration continue, les caches, les images des exécuteurs et toutes les SBOM générées pour les paquets et versions concernés, y compris les paquets liés aux outils de front-end, d'automatisation d'entreprise, de recherche et d'intelligence artificielle
• Si les exécuteurs CI/CD disposaient d'identifiants de publication PyPI lors de l'exécution de paquets npm compromis, veillez à les renouveler également
• Vérifiez les workflows GitHub Actions qui utilisent pull_request_target en association avec un checkout de code non fiable, un GITHUB_TOKEN dont l'accès est limité à l'écriture, des secrets exposés ou la réutilisation du cache au-delà des limites de confiance, car ces combinaisons peuvent permettre la compromission du workflow

3. Mesures stratégiques (cette semaine et au-delà)

• Retards minimaux dans la publication des informations : même un retard de trois jours aurait constitué une marge de manœuvre défensive face à cette campagne, conformément aux recommandations de la CISA visant à atténuer les attaques rapides visant la chaîne d'approvisionnement. Mettez en œuvre cette fonctionnalité via « min-release-age » dans pnpm, ou appliquez-la via un registre proxy ou un moteur de règles de gestion des artefacts pour les gestionnaires de paquets qui ne la prennent pas en charge en natif.
• Fixez les dépendances à des versions précises et appliquez les fichiers de verrouillage, y compris leurs hachages d'intégrité enregistrés
• Définissez « ignore-scripts=true » dans « .npmrc » pour les environnements CI
• Considérez les attaques visant la chaîne d'approvisionnement comme un signe avant-coureur d'une compromission plus large de l'entreprise

Les questions que les équipes de sécurité devraient se poser dès maintenant

Un développeur ou un environnement d'intégration continue a-t-il installé les versions concernées après le 11 mai ?

Si la réponse est oui, partez du principe qu'il y a eu compromission jusqu'à preuve du contraire.

Quels secrets étaient présents dans ces environnements au moment de l'exécution ?

Concentrez-vous en priorité sur le cloud, la publication de paquets, le contrôle de version et les identités de déploiement.

Des référentiels ou des paquets relevant de votre responsabilité ont-ils été modifiés ou republiés de manière inattendue ?

Cette campagne s'est propagée d'elle-même. Votre environnement a peut-être été à la fois une victime et un point de diffusion. Si tel est le cas, vos identifiants de publication ont peut-être été utilisés pour compromettre d'autres comptes.

Pouvez-vous vérifier que la persistance a bien été supprimée des terminaux ?

Ne vous contentez pas de supprimer les modules Node ou de rétablir les fichiers de verrouillage.

Transformer les risques liés à la chaîne d'approvisionnement en mesures concrètes grâce à Tanium

Tanium Guardian et le tableau de bord « Mini Shai-Hulud Supply Chain Compromise » de l' offrent aux équipes de sécurité et d'exploitation informatique une vue partagée et en temps réel de l'état des terminaux sur l'ensemble de la surface d'attaque des développeurs :

• Aidez-nous à identifier les terminaux sur lesquels des paquets npm et PyPI concernés pourraient être exécutés, en utilisant les données SBOM lorsqu'elles sont disponibles
• Étudier les outils de développement de Scope, notamment Node.js, Python et des outils d'IA tels que Claude Code
• Recherchez les indicateurs de persistance — LaunchAgents, services au niveau de l'utilisateur et hooks de démarrage des IDE ou des outils — à l'aide de questions prédéfinies qui s'exécutent sur les données télémétriques en temps réel des terminaux.
• Vérifiez l'état du nettoyage dans l'ensemble des configurations des exécuteurs CI/CD et des surfaces d'exposition des identifiants, et pas uniquement dans les registres de paquets

Les organisations ayant déjà déployé l'agent Tanium peuvent utiliser le contenu Guardian existant sans qu'il soit nécessaire de déployer d'autres agents.

La réponse ne doit pas se limiter à l'examen des registres ou des référentiels. Les points de terminaison des développeurs et les exécuteurs CI/CD font partie de la chaîne d'attaque. Tanium permet aux équipes de sécurité et d'exploitation informatique de confirmer l'exposition aux menaces, de vérifier la suppression des éléments persistants et de coordonner les mesures correctives à partir d'une même vue de l'état actuel, plutôt que de s'appuyer sur des artefacts de compilation statiques ou sur des vérifications manuelles différées.

Foire aux questions concernant l'attaque de la chaîne d'approvisionnement « Mini Shai-Hulud »

Les attaques visant la chaîne d'approvisionnement, telles que « Mini Shai-Hulud », soulèvent des questions qui vont bien au-delà des procédures standard de gestion des incidents de type « ».

Vous trouverez ci-dessous quelques questions fréquemment posées par les équipes de sécurité au sujet de cette campagne et de ses implications pour la confiance dans les logiciels à l'avenir.

Peut-on encore se fier à la traçabilité des paquets ?

Cela peut tout de même s'avérer utile, mais il ne faut pas le considérer comme un indicateur de sécurité exhaustif. La provenance vous indique d'où vient quelque chose. Cela ne prouve pas que ce canal de communication n'ait pas fait l'objet d'abus.

Les équipes devraient-elles retirer immédiatement les jetons volés ?

Pas à l'aveuglette. Dans les incidents impliquant une logique de révocation destructrice, l'isolation et l'enquête doivent primer afin que les mesures d'intervention ne provoquent pas de dommages supplémentaires.

Quelle est la mesure préventive la plus efficace que la plupart des équipes ne mettent toujours pas en œuvre ?

Le fait d'attendre un certain temps avant d'utiliser les nouvelles versions des paquets reste l'une des mesures de contrôle les plus simples et les plus efficaces, notamment face aux événements qui surviennent rapidement au sein de la chaîne d'approvisionnement.

En quoi cette campagne revêt-elle une importance qui dépasse le simple cercle des développeurs ?

En effet, les postes de travail des développeurs et les exécuteurs CI/CD contiennent souvent des identifiants d'accès au cloud, des droits de déploiement et des identités de publication de paquets. Leur compromission peut rapidement se transformer en un incident à plus grande échelle au sein de l'entreprise.

Tanium est conçu pour compléter les initiatives et les contrôles existants en matière de sécurité de la chaîne d’approvisionnement ( ) et de gestion des identités ( ) en reliant l’exposition des paquets, l’état des terminaux, la validation de la persistance et la vérification des réponses. Ainsi, les équipes de sécurité et d’exploitation informatique peuvent agir à partir d’une même vue d’ensemble en temps réel.
Prenez rendez-vous dès aujourd’hui pour une démonstration afin de découvrir comment Tanium coordonne la réponse de la chaîne d’approvisionnement à travers les terminaux et les identités.