La campagne GhostAction détourne des comptes GitHub pour voler des secrets CI/CD et d'IA

Une cybercampagne coordonnée connue sous le nom de GhostAction a compromis environ 1 900 comptes GitHub en octobre 2026. Les attaquants ont utilisé ces points d'accès pour injecter des workflows GitHub Actions malveillants dans plus de 30 000 dépôts, visant à exfiltrer des identifiants sensibles, notamment des clés d'accès cloud et des jetons API de fournisseurs d'IA.

Ce qui s'est passé

L'attaque s'est intensifiée les 8 et 9 octobre 2026, lorsque les acteurs de la menace ont pris pour cible des dépôts appartenant à environ 3 000 utilisateurs et organisations. Durant ce pic, les workflows malveillants ont tenté d'extraire 3 174 secrets distincts. GitGuardian, qui a suivi la campagne, a noté que les attaquants ont déployé la charge utile en plusieurs phases. Une première poussée visait environ 160 comptes déjà compromis, suivie vingt minutes plus tard par un déploiement beaucoup plus vaste affectant 28 000 nouveaux dépôts.

Contrairement aux attaques précédentes sur la chaîne d'approvisionnement qui exploitaient des vulnérabilités dans des actions partagées, comme la compromission de tj-actions/changed-files, GhostAction reposait sur des identifiants de développeurs volés. L'analyse de StepSecurity du 9 octobre suggère que les attaquants ont probablement utilisé des jetons d'accès personnels obtenus via des dumps d'identifiants, bien que la source initiale de ces identifiants reste non confirmée. Avec un accès en écriture valide, les attaquants ont modifié directement les workflows des dépôts, contournant ainsi la nécessité d'une quelconque vulnérabilité dans la plateforme GitHub Actions elle-même.

Les fichiers malveillants étaient déguisés avec des noms anodins tels que security-audit.yml ou github_actions_security.yml. Ces faux jobs faisaient référence à des secrets déjà utilisés par les processus de build légitimes, leur permettant de s'exécuter sans éveiller immédiatement de soupçons tout en collectant des identifiants en arrière-plan. Les contrôles d'approbation de GitHub ont bloqué bon nombre de ces workflows, mais les attaquants se sont adaptés en recyclant 92 anciens workflows issus d'attaques précédentes, dont certains étaient actifs depuis septembre 2025.

Comment cela fonctionne

Le mécanisme central de l'attaque impliquait l'injection de fichiers de workflow YAML qui exécutaient des actions de checkout standard avec une récupération agressive de l'historique. Plus précisément, les workflows utilisaient actions/checkout@v4 avec le paramètre fetch-depth: 0. Cette configuration instruit le runner de télécharger l'intégralité de l'historique Git plutôt que seulement le dernier commit. En accédant à l'historique complet, les scripts malveillants pouvaient scanner non seulement l'arborescence de travail actuelle, mais aussi les commits passés à la recherche de secrets codés en dur.

Les scanners recherchaient un large éventail d'identifiants, y compris les clés AWS, les jetons d'accès personnels GitHub et GitLab, les clés Google et Firebase, ainsi que les jetons API de fournisseurs d'IA tels qu'Anthropic, OpenAI et OpenRouter. Les itérations ultérieures du malware ont amélioré leur logique d'extraction en capturant les lignes de code environnantes, leur permettant d'associer les ID de clés AWS à leurs clés d'accès secrètes correspondantes, même si elles étaient séparées dans la structure du fichier.

Une fois collectés, les identifiants étaient envoyés via HTTP vers un serveur contrôlé par l'attaquant à l'adresse IP 193.32.204.199. Cette méthode permettait aux attaquants de récupérer des clés qui avaient été retirées de la base de code actuelle il y a des mois ou des années, mais qui restaient accessibles dans l'historique Git. Le processus d'exfiltration était silencieux, tirant parti de l'environnement d'exécution légitime de GitHub Actions pour se fondre dans le trafic CI/CD normal.

Détails clés

• Environ 1 900 comptes GitHub ont été compromis pour faciliter l'attaque.
• Des workflows malveillants ont été injectés dans plus de 30 000 dépôts répartis entre 3 000 utilisateurs et organisations.
• Les attaquants ont ciblé 3 174 secrets, y compris des clés cloud et des jetons API de fournisseurs d'IA.
• Les workflows utilisaient fetch-depth: 0 pour scanner l'historique Git complet à la recherche d'identifiants précédemment supprimés.
• Les données exfiltrées ont été envoyées via HTTP à l'adresse IP 193.32.204.199.
• Seuls 16 % des dépôts affectés lors des premières phases avaient été nettoyés au 5 octobre.

Pourquoi c'est important

Cet incident met en évidence un angle mort critique dans la sécurité moderne du développement : la persistance des secrets dans l'historique Git. De nombreuses équipes supposent que la suppression d'une clé codée en dur de la branche actuelle élimine le risque. Cependant, comme Git est immuable par conception, ces secrets restent dans l'historique sauf s'ils sont explicitement purgés. La campagne GhostAction démontre que les attaquants exploitent activement cette faille, utilisant des outils CI/CD standards pour exhumer d'anciens identifiants que les développeurs ont peut-être oubliés.

Pour les responsables de l'ingénierie et les équipes DevOps, la dépendance aux contrôles d'approbation natifs de GitHub est insuffisante. Bien que GitHub ait bloqué de nombreuses exécutions malveillantes, la capacité des attaquants à recycler d'anciens workflows et à utiliser des identifiants valides signifiait que certaines exfiltrations se produisaient encore. Le fait que seuls 16 % des dépôts précédemment affectés aient été nettoyés des mois après la détection initiale suggère un retard significatif dans les efforts de réponse aux incidents et de remédiation à travers l'écosystème.

De plus, le ciblage des clés de fournisseurs d'IA signale un changement dans les priorités des attaquants. À mesure que les entreprises intègrent davantage de services d'IA dans leurs produits, les jetons API pour des fournisseurs comme OpenAI et Anthropic sont devenus des cibles de haute valeur. Compromettre ces clés peut entraîner non seulement des pertes financières dues à une utilisation non autorisée, mais aussi des fuites potentielles de données si les clés donnent accès à des modèles propriétaires ou à des données clients traitées par ces services.

Ce que vous pouvez faire

• Auditez les journaux d'audit GitHub et l'activité des jetons d'accès personnels pour identifier tout compte ayant récemment modifié .github/workflows/.
• Examinez les historiques d'exécution de GitHub Actions pour détecter les jobs qui se sont exécutés de manière inattendue ou qui ont accédé à des secrets dont ils n'avaient pas besoin.
• Révoquez immédiatement les identifiants de tout compte compromis, même si le workflow malveillant a déjà été supprimé.
• Faites pivoter toutes les clés cloud, les identifiants de déploiement, les jetons de registre et les clés API de fournisseurs d'IA qui pourraient avoir été exposés.
• Scannez votre historique Git complet à la recherche de secrets codés en dur, et pas seulement la tête actuelle, en utilisant des outils conçus pour l'inspection approfondie de l'historique.
• Mettez en œuvre des exigences strictes d'approbation pour les modifications de workflow et limitez la portée des jetons d'accès personnels utilisés dans le CI/CD.