Seul un jour s'est écoulé depuis que la deuxième attaque de la chaîne d'approvisionnement Shai Hulud a secoué l'écosystème, et de nouveaux utilisateurs et organisations sont encore compromis chaque heure. Alors que nous passons au crible les retombées, nous commençons à découvrir le vecteur d'infection initial que les attaquants ont utilisé pour compromettre des projets majeurs comme AsyncAPI, PostHog et Postman, et il devient clair que nous n'avons pas encore vu l'ampleur totale de cette campagne. En exploitant des vulnérabilités subtiles mais puissantes dans les workflows GitHub Actions, les attaquants ont démontré une évolution préoccupante de leurs méthodes de livraison. C'est un rappel puissant 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 tenons souvent pour acquise.
Chronologie de la campagne Shai-Hulud
- 27 août - Nous publions notre rapport détaillant la campagne S1ngularity ciblant plusieurs packages 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 de suivi, approfondissant les particularités techniques de la campagne et le comportement initial de la charge utile.
- 24 novembre - Une deuxième attaque a lieu, surnommée le « Second Coming » par les attaquants, juste avant la date limite de npm pour la révocation des anciens tokens.
- 25 novembre - Nous découvrons le vecteur d'entrée initial des attaquants via des workflows GitHub Actions vulnérables dans des projets comme AsyncAPI, PostHog et Postman.
Un rapide rappel
Depuis la faille 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 d'incidents précédents, la méthode était simple. L'attaquant a implanté une porte dérobée délibérée dans un fichier de workflow, et cette porte dérobée a discrètement transmis des informations sensibles, y compris des identifiants, à un endpoint contrôlé par l'attaquant.
Ce que nous observons dans la dernière vague de la campagne Shai Hulud est plus avancé. Au lieu d'insérer directement des portes dérobées, les attaquants exploitent désormais des vulnérabilités dans les workflows GitHub Actions existants pour exécuter leur attaque. Ce changement de technique leur a permis de compromettre des projets comme 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 sont immédiatement apparus comme des anomalies, et une analyse plus approfondie a montré qu'ils avaient probablement tous été implantés manuellement par l'attaquant via l'exploitation de GitHub Actions. Nous avons ensuite été informés par un tiers d'une extension OpenVSX malveillante connexe présentant un schéma similaire. Cette découverte a confirmé que les attaquants ont fait évoluer leurs méthodes et exploitent désormais les mauvaises configurations CI dans le cadre de leur chaîne d'intrusion.
Comment l'attaquant a utilisé les vulnérabilités de GitHub Actions
Les workflows GitHub Actions sont des scripts automatisés qui s'exécutent au sein d'un dépôt 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 s'accompagne de risques, surtout 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 workflow, y compris pull_request_target et workflow_run, peuvent devenir dangereux lorsqu'ils sont mal configurés. C'est exactement ce qui s'est passé dans le cas de PostHog, comme le montre la capture d'écran. Le problème a été porté à l'attention du public par Adnan Khan, un chercheur en sécurité qui a mis en évidence le workflow vulnérable dans un post X. L'attaque a probablement été causée par une vulnérabilité dans le .github/workflows/auto-assign-reviewers.yml workflow. Ce fichier utilisait le déclencheur risqué pull_request_target d'une manière qui permettait l'exécution du code fourni par toute nouvelle pull request pendant l'exécution CI. La vulnérabilité a été introduite pour la première fois le 11 septembre 2025 via une pull request fusionnée, où elle est restée disponible jusqu'à l'attaque Shai Hulud. Au total, le problème était présent pendant 74 jours avant que l'attaquant ne l'exploite.
Un schéma similaire apparaît dans le dépôt AsyncAPI. Nous avons constaté que leur .github/workflows/auto-changeset.yml fichier contenait une configuration vulnérable ajoutée le 9 septembre 2025. L'équipe AsyncAPI a depuis supprimé le fichier suite à notre recommandation, mais la configuration est restée disponible suffisamment longtemps pour que l'attaquant inclue ce projet dans la campagne.
Il convient de noter que l'un de ces projets utilisait déjà un outil de scan de PR, mais il n'a pas réussi à détecter les vulnérabilités cachées dans les workflows 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é 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 identifie un workflow exploitable dans un projet, cette seule faiblesse peut servir de point d'ancrage pour une attaque qui se propage à une échelle jamais vue auparavant, comme l'a démontré le ver Shai Hulud.
Ce que vous devez savoir et les actions à entreprendre
À mesure que ces menaces continuent d'évoluer, il devient de plus en plus important de comprendre comment les vulnérabilités dans les workflows GitHub Actions peuvent exposer non seulement votre propre projet, mais aussi chaque projet et utilisateur qui y est connecté. Une seule mauvaise configuration peut transformer un dépôt en patient zéro pour une attaque à propagation rapide, donnant à un adversaire la capacité d'injecter du code malveillant via les pipelines automatisés sur lesquels vous comptez quotidiennement. Les développeurs ne peuvent se défendre que contre ce qu'ils connaissent, il est donc essentiel de connaître les modèles de workflow dangereux tels que pull_request_target et workflow_run est essentielle. Une autre option consiste à utiliser une plateforme de sécurité comme Aikido qui scanne automatiquement les dépôts et les pull requests entrantes à la recherche de ce type de vulnérabilités.
Il est tout aussi important de rester conscient des vulnérabilités dans les dépendances que vous installez. Même si vos propres workflows sont sécurisés, des packages compromis en amont peuvent toujours introduire des risques. C'est là que les capacités SCA d'Aikido, la base de données de vulnérabilités Intel et les informations sur la santé des packages sont particulièrement utiles, aidant les équipes à détecter les problèmes tôt 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 d'arrêter les malwares en temps réel dès leur apparition peut prévenir une infection grave. C'est l'idée derrière Aikido Safe Chain, un outil gratuit qui s'intègre à npm et utilise à la fois l'IA et des chercheurs en malwares humains pour détecter et bloquer les derniers risques de la chaîne d'approvisionnement avant qu'ils n'entrent dans votre environnement.
