GhostAction : 772 repos GitHub piégés, 2 577 secrets CI/CD volés

Les faits

La campagne GhostAction, identifiée pour la première fois par GitGuardian en septembre 2025, est revenue en force lors d'une nouvelle vague d'attaques couvrant la période du 31 août au 30 septembre 2026. Cette nouvelle offensive a compromis 772 dépôts publics GitHub appartenant à 373 utilisateurs et organisations, exfiltrant 2 577 secrets CI/CD incluant des clés cloud AWS, Google Cloud et Azure, des credentials SSH, des tokens d'accès à des registres de conteneurs, des mots de passe de bases de données et des tokens GitHub à haute valeur.

Le mécanisme d'attaque repose sur une technique à la fois simple et redoutablement efficace. L'attaquant commence par compromettre des comptes GitHub de développeurs, probablement via du credential stuffing ou du phishing ciblé. Une fois le compte contrôlé, il injecte dans les dépôts de la victime un fichier de workflow malveillant nommé github_actions_security.yml, accompagné d'un message de commit anodin : «Add Github Actions Security workflow». Ce nom joue sur la légitimité apparente d'un audit de sécurité automatisé, réduisant la méfiance des mainteneurs qui pourraient examiner les commits récents.

Le workflow malveillant est conçu avec une précision chirurgicale. Avant l'injection, l'attaquant analyse les workflows légitimes existants dans le dépôt ciblé pour identifier les noms exacts des secrets référencés dans les variables d'environnement. Il intègre ensuite ces noms directement dans le code du workflow malveillant, ciblant uniquement les secrets présents et évitant les erreurs qui trahiraient l'intrusion. Lors de l'exécution déclenchée par un push ou une pull request, le workflow collecte les valeurs de ces secrets et les transmet en une seule requête HTTP POST vers une infrastructure contrôlée par l'attaquant.

La campagne GhostAction n'est pas nouvelle. GitGuardian avait documenté une première vague en septembre 2025 ayant touché 817 dépôts publics répartis sur 327 utilisateurs GitHub, avec l'exfiltration d'au moins 3 325 secrets. La deuxième vague d'août-septembre 2026 a été moins volumineuse en nombre de dépôts mais tout aussi efficace sur l'exfiltration. Selon les dernières analyses disponibles au 16 octobre 2026, une troisième vague serait en cours, ayant touché plus de 30 000 dépôts supplémentaires avec des modalités d'exfiltration confirmées.

Parmi les victimes documentées dans la dernière vague, on retrouve des comptes GitHub de mainteneurs de projets open source à forte audience : Takashi Kitao, mainteneur du moteur de jeu Pyxel, et Henry Wu, auteur de l'athenadriver Uber, ont été cités par les chercheurs d'Aviatrix comme exemples de comptes compromis. La compromission de mainteneurs de projets populaires est particulièrement dangereuse car leurs dépôts sont automatiquement clonés et utilisés par des milliers d'organisations downstream, multipliant la surface d'impact potentiel.

L'infrastructure d'exfiltration utilisée par GhostAction communique via des connexions HTTP non chiffrées vers des serveurs de collecte rotatifs, une caractéristique qui facilite la détection par les outils de surveillance réseau mais qui passe souvent inaperçue dans les environnements CI/CD où les connexions sortantes ne sont pas filtrées. Les secrets exfiltrés incluent systématiquement les tokens GitHub à longue durée de vie, les API keys de services cloud, et dans 23 % des cas documentés, des credentials donnant accès à des environnements de production directement.

GitHub a été notifié par GitGuardian et a commencé à invalider les tokens compromis identifiés, mais la vitesse d'exfiltration — quelques secondes entre l'exécution du workflow et la transmission — rend la protection post-facto difficile. Les attaquants peuvent utiliser les credentials volés bien avant que GitHub ne procède aux révocations. La CISA n'a pas encore émis d'advisory spécifique sur GhostAction au 16 octobre 2026, mais le sujet est mentionné dans plusieurs bulletins de threat intelligence hebdomadaires diffusés aux ISAC sectoriels.

La portée réelle de la campagne pourrait être significativement plus large que les 772 dépôts documentés dans la vague d'août-septembre. Les chercheurs de GitGuardian précisent que leur détection repose sur des dépôts publics analysés dans leur infrastructure de surveillance ; les dépôts privés compromis ne seraient pas comptabilisés dans ces chiffres. Pour une organisation utilisant GitHub Enterprise avec des runners self-hosted, l'impact potentiel dépasse largement les secrets GitHub natifs et peut inclure des accès à l'ensemble de l'infrastructure interne.

Impact et exposition

Les organisations les plus exposées sont celles qui utilisent GitHub Actions avec des secrets stockés au niveau repository ou organisation sans rotation régulière. Les environnements où les workflows CI/CD disposent d'accès cloud avec des permissions larges (déploiement, modification d'infrastructure, accès aux bases de données) sont particulièrement à risque : un secret de déploiement volé peut permettre la compromission totale d'un environnement de production en quelques minutes.

Les projets open source avec de nombreux contributeurs présentent une surface d'attaque plus large car chaque compte contributeur représente un vecteur d'injection potentiel. Les organisations qui forkent des dépôts publics populaires et en héritent les workflows sont également exposées si des modifications malveillantes ont été introduites upstream.

Recommandations

• Auditer immédiatement tous les fichiers .github/workflows/ dans vos dépôts, en cherchant spécifiquement le fichier github_actions_security.yml et tout workflow créé récemment par des contributeurs inconnus
• Révoquer et regénérer tous les secrets GitHub Actions des dépôts qui auraient pu être ciblés, particulièrement les tokens cloud et les credentials de déploiement
• Activer la protection des secrets GitHub (Secret scanning + push protection) sur tous vos dépôts
• Restreindre les permissions des workflows : appliquer le principe de moindre privilège, limiter les tokens GITHUB_TOKEN aux permissions strictement nécessaires
• Mettre en place une politique de review obligatoire pour tout ajout ou modification de fichier workflow, y compris dans les forks
• Activer l'authentification MFA sur tous les comptes GitHub ayant un accès en écriture aux dépôts de l'organisation