Un jour seulement s'est écoulé depuis que la deuxième attaque de la chaîne d'approvisionnement Shai Hulud s'est propagée dans l'écosystème, et de nouveaux utilisateurs et organisations sont encore compromis chaque heure. En analysant les conséquences, nous commençons à découvrir le vecteur d'infection initial utilisé par les attaquants pour compromettre des projets majeurs tels que AsyncAPI, PostHog et Postman, et il devient clair que nous n'avons pas encore vu toute l'étendue de cette campagne. En exploitant des vulnérabilités subtiles mais puissantes dans les workflows GitHub Actions, les attaquants ont démontré une évolution inquiétante dans leurs méthodes de livraison. Cela nous rappelle avec force que nos défenses doivent évoluer tout aussi rapidement et que la sécurité de l'écosystème open source dépend du renforcement continu de l'infrastructure que nous considérons souvent comme acquise.
Chronologie de la campagne Shai-Hulud
- 27 août - Nous publions notre rapport détaillant la campagne S1ngularity visant plusieurs paquets nx sur npm.
- 16 septembre - L'attaquant frappe à nouveau, lançant la première vague des attaques Shai-Hulud.
- 18 septembre - Nous publions une analyse complémentaire, qui examine plus en détail les particularités techniques de la campagne et le comportement initial de la charge utile.
- 24 novembre - Une deuxième attaque, baptisée « Second Coming » (seconde venue) par les pirates, a lieu juste avant la date limite fixée par npm pour révoquer les anciens jetons.
- 25 novembre - Nous découvrons le vecteur d'entrée initial des attaquants via des workflows GitHub Actions vulnérables dans des projets tels que AsyncAPI, PostHog et Postman.
Un petit rappel
Depuis la violation Nx et l'attaque Shai Hulud, nous savons que l'attaquant a abusé des workflows GitHub Actions pour exfiltrer des données via des liens webhook.site. Lors des incidents précédents, la méthode était simple. L'attaquant avait délibérément implanté une porte dérobée dans un fichier de workflow, et cette porte dérobée transmettait discrètement des informations sensibles, notamment des identifiants, à un terminal contrôlé par l'attaquant.
Ce que nous observons dans la dernière vague de la campagne Shai Hulud est plus sophistiqué. Au lieu d'insérer directement des portes dérobées, les pirates exploitent désormais les vulnérabilités des workflows GitHub Actions existants pour mener leur attaque. C'est ce changement de technique qui leur a permis de compromettre des projets tels que AsyncAPI, PostHog et Postman lors de l'attaque Shai-Hulud d'hier.
Notre enquête a débuté lorsque nous avons remarqué plusieurs téléchargements suspects sur NPM liés à des noms d'utilisateur inattendus tels que « codespace » et « runner ». Ces téléchargements ont immédiatement été identifiés comme des anomalies, et une analyse plus approfondie a montré qu'ils avaient probablement tous été effectués manuellement par le pirate via l'exploitation de GitHub Actions. Nous avons ensuite été informés par un tiers de l'existence d'une extension OpenVSX malveillante présentant un schéma similaire. Cette découverte a confirmé que les attaquants avaient fait évoluer leurs méthodes et exploitaient désormais les erreurs de configuration CI dans le cadre de leur chaîne d'intrusion.
Comment l'attaquant a exploité les vulnérabilités de GitHub Actions
Les workflows GitHub Actions sont des scripts automatisés qui s'exécutent dans un référentiel pour gérer des tâches telles que les tests, la compilation, la publication ou la gestion des pull requests. Ils sont puissants et flexibles, mais cette puissance comporte des risques, en particulier lorsque les workflows sont configurés sans une compréhension complète de la manière dont ils exécutent du code non fiable.
Certains déclencheurs de flux de travail, notamment pull_request_target et exécution_du_flux_de_travail, peut devenir dangereux s'il est mal configuré. C'est exactement ce qui s'est passé dans le cas de PostHog, comme le montre la capture d'écran. Le problème a d'abord été porté à l'attention du grand public par Adnan Khan, un chercheur en sécurité qui a mis en évidence la vulnérabilité du flux de travail dans un message X. L'attaque a probablement été causée par une vulnérabilité au sein du .github/workflows/auto-assign-reviewers.yml workflow. Ce fichier utilisait le risqué pull_request_target déclencher de manière à permettre l'exécution du code fourni par toute nouvelle demande d'extraction pendant le cycle d'intégration continue. La vulnérabilité a été introduite pour la première fois le 11 septembre 2025 par le biais d'une demande d'extraction fusionnée, où elle est restée disponible jusqu'à l'attaque Shai Hulud. Au total, le problème a été présent pendant 74 jours avant que l'attaquant ne l'exploite.
Une tendance similaire apparaît dans le référentiel AsyncAPI. Nous avons constaté que leur .github/workflows/auto-changeset.yml Le fichier contenait une configuration vulnérable ajoutée le 9 septembre 2025. L'équipe AsyncAPI a depuis supprimé le fichier conformément à notre recommandation, mais la configuration est restée disponible suffisamment longtemps pour que le pirate puisse inclure ce projet dans sa campagne.
Il convient de noter que l'un de ces projets utilisait déjà un outil d'analyse des relations publiques, mais qu'il n'a toujours pas réussi à détecter les vulnérabilités cachées dans les flux de travail GitHub Actions. Dans le cas de PostHog, GitHub a signalé la vulnérabilité, mais cet avertissement est resté sans suite. Cela souligne la nécessité de disposer d'outils de sécurité capables de comprendre et de signaler les problèmes sur un large éventail de systèmes et de langages, y compris les vulnérabilités de configuration CI. Une fois qu'un attaquant a identifié un workflow exploitable dans un projet, cette seule faiblesse peut servir de point d'ancrage à une attaque qui se propage à une échelle sans précédent, comme l'a démontré le ver Shai Hulud.
Ce que vous devez savoir et les mesures à prendre
À mesure que ces menaces continuent d'évoluer, il devient de plus en plus important de comprendre comment les vulnérabilités des workflows GitHub Actions peuvent exposer non seulement votre propre projet, mais aussi tous les projets et utilisateurs qui y sont connectés. Une seule erreur de configuration peut transformer un référentiel en patient zéro pour une attaque à propagation rapide, donnant à un adversaire la possibilité d'injecter du code malveillant dans les pipelines automatisés sur lesquels vous comptez chaque jour. Les développeurs ne peuvent se défendre que contre ce qu'ils connaissent, c'est pourquoi il est important de connaître les modèles de workflow dangereux tels que pull_request_target et exécution_du_flux_de_travail est indispensable. Une autre option consiste à utiliser une plateforme de sécurité telle Aikido analyse automatiquement les référentiels et les demandes d'extraction entrantes à la recherche de ce type de vulnérabilités.
Il est tout aussi important de rester conscient des vulnérabilités des dépendances que vous installez. Même si vos propres workflows sont sécurisés, des paquets compromis en amont peuvent toujours présenter un risque. C'est là que SCA Aikido, la base de données Intel Vulnerability Database et les informations Package Health sont particulièrement utiles, car elles aident les équipes à détecter les problèmes à un stade précoce et à comprendre si les bibliothèques sur lesquelles elles s'appuient présentent des signes de compromission ou d'activité suspecte.
Enfin, disposer d'un outil capable de bloquer les logiciels malveillants en temps réel dès leur apparition peut prévenir une infection grave. C'est le principe qui sous-tend Aikido Chain, un outil gratuit qui s'intègre à npm et utilise à la fois l'IA et des chercheurs en logiciels malveillants pour détecter et bloquer les derniers risques liés à la chaîne d'approvisionnement avant qu'ils ne pénètrent dans votre environnement.
Sécurisez votre logiciel dès maintenant.
.avif)
