GhostAction injecte un workflow voleur de secrets dans des dizaines de milliers de dépôts GitHub
La campagne GhostAction compromet des comptes mainteneurs pour pousser un faux workflow de « sécurité » qui exfiltre les secrets CI/CD vers une IP contrôlée. Vérifiez vos dépôts pour les fichiers security-audit.yml et github_actions_security.yml, puis révoquez les identifiants concernés.
7 octobre 2026. La campagne GhostAction reprend : plus de 500 comptes GitHub ont déjà poussé un workflow malveillant vers des dizaines de milliers de dépôts, selon Socket. 9 octobre 2026. StepSecurity détaille deux comptes mainteneurs compromis — celui de Takashi Kitao, auteur du moteur de jeu pyxel (18 400 étoiles), et celui de Henry Wu, auteur initial du pilote athenadriver d’Uber. 9 octobre 2026. GitGuardian chiffre à 772 dépôts publics et 2 577 secrets la récolte de la campagne entre le 31 août et le 30 septembre. Pourquoi c’est important : l’attaquant n’exploite pas une faille du produit — il détourne l’identité du mainteneur, le maillon le plus difficile à surveiller d’une chaîne CI/CD.
Le point d’entrée n’est pas un bug, c’est un jeton
GhostAction n’est pas une nouveauté. La campagne est documentée depuis septembre 2025, où elle avait touché 817 dépôts sur 327 comptes et exfiltré 3 325 secrets — jetons PyPI, npm et DockerHub. Son mode opératoire n’a pas changé : l’attaquant obtient les identifiants d’un mainteneur, très probablement un jeton d’accès personnel (PAT) fuité dans des journaux d’infostealers ou des bases d’identifiants.
À partir de là, tout se joue sous l’identité légitime de la victime. Le compte de Takashi Kitao a poussé le workflow malveillant vers 27 dépôts à partir de 13 h 20 UTC. Huit heures plus tard, celui de Henry Wu faisait de même vers 318 dépôts en une fenêtre de 16 minutes, entre 21 h 10 et 21 h 26 UTC. La vitesse n’est pas celle d’un exploit — c’est celle d’un push authentifié.
L’implication est brutale : les mécanismes de protection qui reposent sur l’identité du commiteur — revue de code, branch protection, exigence de signature — sont contournés, parce que le commiteur est le mainteneur lui-même.
Ce que fait exactement le workflow
Le workflow injecté porte un nom rassurant : security-audit.yml ou github_actions_security.yml. Il se présente comme un audit de sécurité, alors qu’il fait l’inverse — il exfiltre des données sensibles vers une adresse IP codée en dur, 193.32.204[.]199, en HTTP clair.
Son déclencheur est large : workflow_dispatch et un push non filtré (n’importe quelle branche, n’importe quel tag). Il effectue un checkout avec fetch-depth: 0 — c’est-à-dire l’intégralité de l’historique Git — puis exécute une unique étape « Audit » qui fait quatre choses, d’après StepSecurity :
- Ajouter les secrets nommés du dépôt repérés pendant la reconnaissance ;
- Scanner l’arbre de travail à la recherche de 13 motifs d’identifiants (clés AWS, services d’IA, contrôle de sources, API SaaS et cloud) ;
- Parcourir tout l’historique Git à la recherche des mêmes 13 motifs, pour récolter des identifiants commités par erreur puis supprimés ;
- Apparier les identifiants de clé d’accès AWS avec leurs clés secrètes correspondantes.
La récolte est large par conception : secrets nommés GitHub Actions, identifiants CI/CD, clés AWS, clés Anthropic, OpenAI et OpenRouter, jetons GitHub et GitLab. Le fait d’exfiltrer en HTTP clair vers une IP nue dit quelque chose de la confiance de l’attaquant — l’opération vise le volume, pas la discrétion réseau.
Une récolte industrielle, pas chirurgicale
Les chiffres de GitGuardian donnent l’échelle. Entre le 31 août et le 30 septembre 2026, le workflow malveillant a été poussé vers 772 dépôts publics appartenant à 373 comptes et organisations. Il a ciblé 2 577 secrets : clés privées SSH, identifiants Azure, DockerHub et GHCR, bases de données, clés AWS, FTP, Google Cloud et Firebase, jetons GitHub, jetons de bots Telegram, Slack et Discord, et des clés Cloudflare, npm, PyPI et de fournisseurs d’IA.
La campagne n’est pas restée strictement dans l’exfiltration. Dans au moins un cas, le 30 août, les attaquants ont modifié le dépôt kuafuai/DevOpsGPT pour embarquer un mineur XMRig dans l’image Docker du projet. À ce jour, aucune publication malveillante n’a été effectuée avec les identifiants de publication volés — mais les jetons PyPI et npm récoltés constituent une bombe à retardement : ils permettent, le moment venu, d’empoisonner un paquet légitime.
Un détail rend l’affaire plus préoccupante encore. Socket relève que les 279 forks du compte henrywoo héritent chacun du fichier de workflow. Si les Actions sont activées sur un fork, un simple push ultérieur peut déclencher la récolte. Les forks privés et les miroirs aval sont les plus exposés, car c’est dans les dépôts privés que se trouvent réellement les identifiants commités. Pire : chaque exécution renvoie un identifiant de dépôt, qu’un secret soit trouvé ou non — l’opérateur conserve donc une cartographie des contextes d’exécution accessibles, indépendante de toute récolte.
Ce que GhostAction change par rapport au vol de tags
Le réflexe serait de ranger GhostAction avec les attaques de tag hijacking qui ont frappé tj-actions ou Nx. Ce serait une erreur de catégorie. Le vol de tag repose sur la résolution différée d’une référence : uses: actions/checkout@v4 pointe vers un commit muable, et l’attaquant repositionne le tag. La parade documentée est l’épinglage par SHA.
GhostAction joue sur un autre registre. Le workflow malveillant n’est pas une dépendance résolue au moment du build : il est commité directement dans le dépôt, sur la branche par défaut, sous l’identité du mainteneur légitime. Aucun épinglage ne protège contre cela, parce qu’il n’y a rien à épingler — le fichier malveillant est un fichier source comme un autre.
La conséquence est que les défenses « classiques » de la supply chain — signature de commits, revue de code, branch protection — perdent leur efficacité quand l’attaquant possède le compte. La revue voit un push du mainteneur ; la signature est valide ; la branche est protégée mais le propriétaire pousse légitimement. C’est exactement le point aveugle que GhostAction exploite depuis septembre 2025.
La leçon n’est donc pas « épinglez vos actions » — même si cela reste indispensable — mais « protégez les identifiants de vos mainteneurs comme la frontière qu’ils sont ». Un PAT fuité, c’est déjà la moitié de l’attaque accomplie.
Ce qu’il faut faire
La remédiation combine une vérification immédiate et une rotation des identifiants, dans cet ordre.
- Chercher les deux fichiers de workflow. Depuis le 31 août 2026, toute présence de
security-audit.ymlougithub_actions_security.ymldans un dépôt doit être traitée comme une compromission avérée. - Supprimer le workflow de toutes les branches. Le fichier peut résider sur la branche par défaut comme sur des branches secondaires. Supprimez-le partout, y compris dans les forks.
- Révoquer et faire tourner les identifiants. Révoquez le jeton GitHub compromis, puis faites tourner tous les secrets exposés — AWS, fournisseurs d’IA, registres de conteneurs, SaaS.
- Auditer les forks. Vérifiez les forks des dépôts infectés : ils héritent du workflow et peuvent le réactiver à leur tour.
- Durcir le pipeline. Épinglez les actions par SHA, restreignez les permissions des
GITHUB_TOKEN, et méfiez-vous de tout workflow qui se déclenche surworkflow_dispatchcombiné à un push non filtré.
Le piège de ce type de campagne est qu’il ne laisse pas de trace de build suspect : le workflow porte un nom légitime et s’exécute dans l’infrastructure de la victime, avec ses droits.
Verdict
Si vous maintenez un dépôt public ou open source, auditez-le dès aujourd’hui pour les deux noms de workflow et considérez toute occurrence comme une compromission : révoquez le PAT, faites tourner les secrets et purgez le fichier de toutes les branches. Si vous gérez des secrets dans GitHub Actions, partez du principe qu’un mainteneur compromis équivaut à vos secrets exposés — bornez les permissions, épinglez les actions et surveillez les déclencheurs larges. GhostAction le prouve une fois de plus : en matière de supply chain, la faille la plus rentable n’est pas dans le code, elle est dans les identifiants de ceux qui le publient.