GhostAction : 500 mainteneurs GitHub compromis en masse

Ce qui s'est passé

La campagne GhostAction, déjà documentée en 2025 pour sa capacité à voler des secrets stockés dans GitHub Actions, est revenue en force cette semaine avec une variante considérablement plus agressive. Entre le 7 et le 9 octobre 2026, des attaquants ont compromis au moins deux comptes de mainteneurs open source réputés — identifiés sous les pseudonymes henrywoo et kitao — pour mener la phase la plus ambitieuse de la campagne à ce jour. Selon les analyses publiées par GitGuardian, StepSecurity et Socket.dev, cette nouvelle vague aurait abouti au vol de 3 325 secrets distincts en l'espace de quelques heures seulement.

L'accès initial repose sur des identifiants volés préalablement à des comptes GitHub disposant de droits d'écriture sur de nombreux dépôts. Les attaquants ont utilisé ces credentials pour pousser, lors de deux fenêtres d'automatisation de quelques minutes chacune, un commit unique ajoutant le fichier .github/workflows/security-audit.yml à chaque dépôt accessible. Au total, 345 dépôts ont été ciblés lors de cette opération. Parmi les victimes figurent des projets de premier plan : le dépôt uber/athenadriver d'Uber et le projet de jeu kitao/pyxel, qui comptabilise plus de 18 000 étoiles sur GitHub.

La méthode de livraison n'est pas nouvelle, mais l'arsenal d'exfiltration a radicalement évolué. Les variantes précédentes de GhostAction se contentaient de voler les secrets nommés stockés dans GitHub Actions Secrets. Cette nouvelle version va beaucoup plus loin : elle utilise un checkout avec l'option fetch-depth:0 pour récupérer l'intégralité de l'historique git du dépôt, puis exécute la commande git log -p --all pour analyser chaque commit jamais poussé. L'objectif est de trouver des secrets committés par erreur et supprimés depuis des années, mais dont les tokens sont encore valides. Cette technique exploite une réalité méconnue mais critique : dans git, la suppression d'un fichier ne supprime pas les données de l'historique, elles restent accessibles via les objets git.

Le périmètre des credentials ciblés s'est également élargi de façon significative. Cette variante intègre des expressions régulières pour identifier des credentials AWS (clés d'accès et tokens de session STS), des clés de service Google Cloud Platform, des tokens Azure Active Directory, mais aussi des clés API pour des services d'intelligence artificielle ainsi que des credentials pour des services tiers comme les passerelles de paiement et les services de messagerie transactionnelle. Cette évolution reflète la montée en puissance des agents IA en production et la multiplication des credentials associés dans les pipelines CI/CD des équipes de développement.

Le serveur de commande et contrôle (C2) utilisé pour l'exfiltration est hébergé à l'adresse IP 193.32.204.199. Une recherche dans GitHub Code Search sur cette adresse au sein des fichiers de workflow retournait, au 9 octobre 2026, 378 dépôts disposant encore d'un workflow malveillant actif sur leur branche par défaut. L'équipe de sécurité de GitHub a procédé à des retraits progressifs, mais la cadence des détections indique que la campagne demeure active. Socket.dev, qui monitore en temps réel les packages npm et les workflows GitHub, a publié une liste d'indicateurs de compromission permettant aux équipes sécurité d'identifier rapidement les dépôts affectés.

StepSecurity a documenté une évolution tactique importante dans la dénomination des workflows malveillants. Le fichier porte délibérément le nom security-audit.yml pour tromper les développeurs lors d'une revue rapide du dépôt. Le contenu du workflow se présente comme un outil d'audit de sécurité légitime, masquant les étapes d'exfiltration derrière des noms de jobs anodins tels que "dependency-check" ou "secret-scanner". Cette technique d'ingénierie sociale au niveau du code est caractéristique des attaques supply chain les plus sophistiquées, où la plausibilité du contenu malveillant est aussi importante que sa fonctionnalité technique.

Amazon Web Services, Google Cloud et Microsoft Azure ont été notifiés des credentials exfiltrés et ont procédé à la révocation automatique de certains tokens détectés comme compromis via leurs systèmes de surveillance internes. AWS a notamment indiqué que son service GuardDuty avait généré des alertes pour plusieurs credentials volés dès leur première utilisation par les attaquants. Cependant, de nombreux credentials — notamment ceux pour les services d'IA et les API tierces — ne bénéficient pas de mécanismes de révocation automatique et requièrent une intervention manuelle des équipes concernées.

Cette nouvelle vague de GhostAction s'inscrit dans une tendance de fond documentée depuis plusieurs années : les attaquants ciblent les mainteneurs de projets open source populaires comme vecteur d'accès initial, sachant que leurs comptes donnent accès à des dizaines ou centaines de dépôts utilisés par des milliers d'organisations en aval. Selon les estimations de GitGuardian, les dépôts affectés cumulent plusieurs centaines de millions de téléchargements mensuels, ce qui donne une mesure de l'impact potentiel en termes de surface d'exposition pour l'écosystème open source mondial.

Pourquoi c'est important

La campagne GhostAction illustre une évolution structurelle dans les attaques supply chain : les attaquants ont compris que l'historique git est une mine d'or largement sous-surveillée. Dans la plupart des organisations, les politiques de rotation des secrets ne couvrent pas les commits passés. Un token AWS committé par inadvertance en 2022 puis supprimé reste, dans la majorité des cas, toujours valide s'il n'a pas été explicitement révoqué dans la console IAM. Les attaquants exploitent précisément cet angle mort entre la politique théorique et la pratique opérationnelle.

L'extension du ciblage aux credentials d'IA représente un tournant significatif dans l'évolution des menaces. Avec la prolifération des agents IA en production, les organisations stockent désormais des clés API à haute valeur dans leurs pipelines CI/CD. Un token pour un service d'IA générative volé peut être utilisé pour des appels API massifs facturés à l'organisation victime, ou pour accéder à des données confidentielles soumises au modèle dans le cadre de traitements métier sensibles. La surface d'attaque associée à l'IA génère ainsi de nouvelles catégories de risques financiers et de confidentialité que les équipes sécurité n'ont pas encore pleinement intégrées dans leurs modèles de menaces.

Du point de vue de la chaîne d'approvisionnement logicielle, cette attaque démontre que même les projets open source de grande réputation ne sont pas à l'abri d'une compromission via les comptes de leurs mainteneurs. Des projets comme kitao/pyxel sont utilisés par des milliers de développeurs. Si un workflow malveillant s'exécute dans la pipeline CI/CD d'un contributeur ou d'un fork utilisateur, les credentials de ce contributeur sont également exposés. L'effet de contagion peut s'étendre bien au-delà des dépôts directement compromis.

Pour les équipes de sécurité, cette campagne doit déclencher une revue immédiate de la politique de gestion des secrets dans les dépôts git. Les outils de scan d'historique git comme truffleHog, gitleaks ou GitGuardian Monitor permettent d'identifier les secrets historiquement exposés. La mise en place du pinning des GitHub Actions — fixant les actions tierces à des SHA de commit plutôt qu'à des tags mutables — réduit significativement la surface d'attaque. L'activation du 2FA obligatoire pour tous les contributeurs avec droits d'écriture est désormais une mesure de base non négociable pour tout projet utilisant GitHub.

Ce qu'il faut retenir

• GhostAction a compromis 500+ comptes GitHub en octobre 2026, exfiltrant 3 325 secrets dont des credentials cloud AWS, GCP, Azure et des clés API pour services d'IA.
• La nouvelle variante analyse l'intégralité de l'historique git pour trouver des secrets anciens encore valides — contournant ainsi les politiques de rotation classiques.
• Action immédiate : auditer les workflows GitHub Actions, scanner l'historique git avec truffleHog ou gitleaks, révoquer tous les credentials potentiellement exposés et activer le 2FA obligatoire.