GhostAction envahit 30 000 dépôts GitHub via faux workflows

Ce qui s'est passé

Le groupe threat actor baptisé GhostAction a frappé de nouveau avec une ampleur sans précédent. Selon les chercheurs de StepSecurity et les analyses de CyberSecurityNews et GBHackers, la campagne a permis la compromission d'au moins 1 900 comptes GitHub, utilisés comme vecteur d'injection pour cibler plus de 30 000 dépôts publics entre début septembre et le 9 octobre 2026. L'opération constitue l'une des attaques supply chain les plus massives jamais documentées sur la plateforme GitHub.

Le modus operandi de GhostAction repose sur une technique précise : le groupe compromet d'abord des comptes de mainteneurs open source à forts privilèges, puis exploite ces accès pour pousser directement dans les branches principales un fichier de workflow intitulé security-audit.yml. Ce nom est soigneusement choisi pour paraître légitime aux yeux des équipes de sécurité et passer inaperçu dans les revues de code automatisées.

Le 8 octobre 2026, les analystes de StepSecurity ont observé deux fenêtres d'activité automatisée de quelques minutes à peine, au cours desquelles 345 dépôts ont été compromis en un seul balayage. Les victimes identifiées incluent le dépôt uber/athenadriver d'Uber et le projet Python kitao/pyxel, un moteur de jeu rétro comptant plus de 18 000 étoiles sur GitHub. Ces deux dépôts sont liés aux comptes compromis des mainteneurs henrywoo et kitao.

Le workflow malveillant s'exécute côté runner GitHub avec des permissions élevées. Il procède à un checkout complet avec l'option fetch-depth: 0, ce qui lui permet d'accéder à l'intégralité de l'historique git — y compris les secrets supprimés dans des commits antérieurs mais toujours présents dans les objets git. Il effectue ensuite une recherche de patterns d'identifiants (tokens API, clés AWS, credentials de base de données, JWT) sur l'ensemble de l'arborescence et de l'historique, puis exfiltre les résultats via une requête HTTP POST vers l'adresse IP 193.32.204[.]199.

La particularité technique la plus préoccupante est cette capacité à explorer l'historique git complet. De nombreuses équipes ont la fausse impression que supprimer un secret dans un commit ultérieur suffit à le neutraliser. GhostAction démontre le contraire : tant que le dépôt n'a pas fait l'objet d'une réécriture d'historique via git filter-repo, les anciennes versions des fichiers restent accessibles et exploitables pour quiconque dispose d'un accès en lecture au dépôt.

L'échelle de l'opération est rendue possible par un degré élevé d'automatisation. Les attaquants ont construit une infrastructure capable d'énumérer automatiquement les dépôts sur lesquels un compte compromis dispose de droits d'écriture, puis d'y injecter le workflow sans passer par le mécanisme de pull request — contournant ainsi les alertes de code review. Cette approche de push direct sur la branche principale exploite les dépôts dont les branch protection rules ne sont pas configurées avec des reviewers obligatoires.

Du côté de GitHub, la plateforme a confirmé avoir détecté et suspendu des comptes impliqués dans la campagne, et travaille à améliorer ses mécanismes de détection des injections de workflows anormaux. StepSecurity a publié une analyse technique détaillée le 9 octobre 2026, permettant aux équipes de sécurité de rechercher des indicateurs de compromission dans leurs organisations GitHub. L'outil Harden-Runner de StepSecurity a permis de détecter les tentatives d'exfiltration réseau depuis les runners en temps réel.

À ce stade, l'attribution de GhostAction reste partielle. Les chercheurs notent des similitudes dans les techniques d'obfuscation et les patterns d'infrastructure avec des campagnes supply chain documentées en 2025, mais aucun lien formel avec un groupe étatique ou criminel connu n'a été établi publiquement. L'opération présente les caractéristiques d'une campagne à motivation financière, avec une revente probable des credentials CI/CD sur des marchés souterrains spécialisés dans la compromission d'infrastructure DevOps.

Pourquoi c'est important

Les attaques sur la chaîne d'approvisionnement logicielle constituent depuis 2020 l'un des vecteurs de menace les plus redoutés par les RSSI. L'incident SolarWinds, puis la compromission de la librairie xz-utils en 2024, ont démontré qu'une seule intrusion dans un outil de développement largement utilisé peut se propager à des milliers d'organisations en aval sans qu'aucune d'entre elles n'ait été directement ciblée. GhostAction s'inscrit dans cette même logique, mais avec une échelle d'automatisation sans précédent sur GitHub.

L'utilisation de GitHub Actions comme vecteur est particulièrement insidieuse parce que ces workflows sont conçus pour s'exécuter avec des privilèges étendus dans les pipelines CI/CD. Un token GitHub Actions compromis peut permettre à un attaquant de publier des packages malveillants sur npm ou PyPI, de déployer du code en production, ou d'accéder à des secrets stockés dans GitHub Secrets ou dans des coffres-forts externes comme HashiCorp Vault ou AWS Secrets Manager. La surface d'impact est exponentiellement plus grande que la compromission initiale du dépôt.

Pour les entreprises qui s'appuient sur des dépendances open source — c'est-à-dire la quasi-totalité des équipes de développement modernes — cet incident rappelle l'importance de ne pas traiter les workflows CI/CD de tiers comme du code de confiance. Les politiques de branch protection, le principe de moindre privilège pour les tokens d'accès, et la surveillance des comportements réseau depuis les runners constituent des contrôles fondamentaux qui restent sous-déployés dans de nombreuses organisations.

D'un point de vue réglementaire, les obligations NIS2 et DORA en Europe imposent aux entités soumises une gestion rigoureuse des risques liés à la chaîne d'approvisionnement. Un incident de type GhostAction pourrait constituer un événement notable à déclarer aux autorités compétentes, en particulier si des secrets permettant l'accès à des systèmes critiques ont été exposés dans les dépôts compromis.

Ce qu'il faut retenir

• Auditer immédiatement tous les workflows GitHub Actions de vos dépôts pour détecter la présence de security-audit.yml ou de tout workflow non reconnu poussé récemment sur une branche principale sans pull request.
• Révoquer et renouveler tous les tokens et secrets GitHub Actions si un compte mainteneurs a pu être compromis, et vérifier l'historique git complet — pas seulement les fichiers actuels.
• Activer les branch protection rules avec reviewers obligatoires sur toutes les branches de production et déployer un outil de surveillance réseau depuis les runners pour détecter les exfiltrations.