GhostAction : un faux workflow « Security Audit » piège des centaines de dépôts GitHub et fouille tout leur historique

Le 8 octobre 2026, deux comptes GitHub appartenant à des développeurs de logiciels libres reconnus ont été détournés pour ajouter, en deux vagues rapides, un même fichier d’automatisation à 345 dépôts. Son nom, « Security Audit », promettait un contrôle de sécurité. Il faisait l’inverse : récupérer les clés d’accès, mots de passe techniques et jetons stockés dans ces projets, puis les expédier vers un serveur contrôlé par les attaquants. Cette campagne, baptisée GhostAction par les chercheurs, n’est pas nouvelle, mais sa dernière version va beaucoup plus loin que la précédente.

Un fichier piégé au nom rassurant

Pour comprendre l’attaque, il faut savoir ce qu’est GitHub Actions : un service d’automatisation intégré à GitHub, qui exécute des tâches comme la compilation, les tests ou le déploiement d’un logiciel. Ces tâches sont décrites dans des workflows, de petits fichiers de configuration rangés dans le dépôt lui-même. Pour publier un paquet ou se connecter à un hébergeur, ils ont souvent besoin de secrets, c’est-à-dire de clés d’accès à des services extérieurs. Les attaquants ont simplement déposé leur propre workflow dans les projets, accompagné d’un message anodin, « Add security audit workflow ». Ces modifications apparaissent sous l’identité réelle des victimes, ce qui les rend difficiles à repérer au premier coup d’œil.

Le premier compte touché est celui de Takashi Kitao, auteur du moteur de jeu pyxel : 27 dépôts ont reçu le fichier piégé. Huit heures plus tard, celui de Henry Wu, auteur à l’origine du projet athenadriver d’Uber, a servi à déposer le même workflow dans 318 dépôts en 16 minutes. La société de sécurité Socket, qui a mené sa propre analyse, compte 346 dépôts touchés : 318 sous le compte de Henry Wu, dont 39 dépôts d’origine et 279 copies (appelées forks), 27 chez Takashi Kitao, et le dépôt uber/athenadriver, qui appartient à Uber et auquel Henry Wu a gardé un accès en écriture.

Tout l’historique passé au crible

La variante la plus ancienne du fichier se contente d’envoyer les secrets déclarés dans le projet. La plus récente récupère en plus l’historique complet du dépôt, c’est-à-dire toutes les versions successives de chaque fichier, sur toutes les branches, et y cherche des identifiants : clés d’accès AWS, le service d’hébergement d’Amazon, jetons GitHub et GitLab, clés Google et Firebase, ainsi que les clés d’API d’OpenAI, d’Anthropic et d’OpenRouter, qui ouvrent l’accès à des services d’intelligence artificielle. Les données partent en clair, par une simple requête HTTP, vers une adresse IP inscrite en dur dans le fichier.

Selon StepSecurity, une clé publiée une seule fois en 2019 et effacée dès le lendemain est récoltée exactement comme les autres.

C’est le point le plus inquiétant de cette nouvelle vague. Un mot de passe ajouté par erreur dans le code, puis supprimé, ne disparaît pas : il reste lisible dans l’historique du projet, et le fichier piégé sait l’y retrouver. StepSecurity, qui a analysé l’attaque en détail, en tire une conclusion sans appel : renouveler les secrets actuellement configurés ne suffit plus à se protéger. Il faut aussi remplacer tout identifiant ayant un jour figuré dans le dépôt, quelle que soit sa branche ou son ancienneté.

Une campagne qui s’étend

L’attaque ne s’est pas arrêtée aux deux comptes du 8 octobre. Selon les mises à jour des chercheurs relayées par GBHackers, la campagne s’est étendue à plus de 500 comptes GitHub compromis et a injecté des workflows malveillants dans des dizaines de milliers de dépôts depuis le 7 octobre 2026. Socket considère le projet pyxel comme le cas le plus net d’identifiants de publication visés par une exécution réussie du fichier piégé : ce sont précisément les clés qui permettent de diffuser une nouvelle version d’un logiciel auprès de ses utilisateurs.

L’attaque a toutefois une limite. Le jeton fourni automatiquement par GitHub au workflow n’avait que des droits de lecture : le fichier piégé ne pouvait donc ni modifier le code, ni publier lui-même une nouvelle version. Au moment de l’analyse de StepSecurity, aucune version malveillante d’un logiciel n’avait été publiée. Mais les identifiants volés, notamment ceux qui servent à publier, restent exploitables tant qu’ils n’ont pas été remplacés : le danger ne s’arrête pas avec la suppression du fichier.

GhostAction n’est pas une nouveauté. En septembre 2025, GitGuardian avait déjà décrit une première campagne du même nom, qui touchait 327 utilisateurs GitHub et 817 dépôts, et dérobait notamment des jetons pour PyPI, npm et DockerHub, trois grands catalogues de logiciels utilisés par les développeurs. Reste une inconnue de taille : la manière dont les attaquants obtiennent les identifiants des comptes détournés. Socket indique ne pas l’avoir observée.

Que faire si vous publiez sur GitHub

Pour les développeurs, les associations ou les petites entreprises qui hébergent du code sur GitHub, la première étape consiste à vérifier si un workflow nommé « Security Audit » ou « Github Actions Security » est apparu dans leurs projets. Socket recommande de supprimer le fichier et d’annuler la modification sur chaque dépôt concerné, y compris ceux qui appartiennent à une organisation. StepSecurity conseille ensuite d’examiner toutes les exécutions de workflows depuis le 31 août 2026, pour savoir si le fichier a eu le temps de s’exécuter.

Il faut ensuite remplacer tous les identifiants que le balayage de l’historique a pu atteindre, et pas seulement ceux qui sont configurés aujourd’hui. Cybersecurity News rappelle que supprimer le fichier ne suffit pas : les équipes touchées doivent révoquer les sessions GitHub, les jetons d’accès personnels, les autorisations OAuth accordées à des applications et les clés SSH. Pour l’avenir, GitHub propose une protection à l’envoi, intégrée à son analyse des secrets, conçue pour empêcher qu’un identifiant écrit en dur dans le code n’arrive dans le dépôt.

Cette affaire rappelle deux règles simples, valables bien au-delà de GitHub. D’abord, un identifiant écrit un jour dans du code partagé doit être considéré comme exposé, même s’il a été effacé depuis : la seule réponse fiable est de le remplacer. Ensuite, un nom rassurant ne garantit rien. Le fichier malveillant se présentait comme un audit de sécurité, et son message de modification semblait parfaitement banal. Activer la double authentification sur ses comptes et limiter les droits de chaque jeton d’accès au strict nécessaire réduisent les dégâts possibles.

Pour une TPE, une association ou un particulier qui publie un site ou un petit outil sur GitHub, l’enjeu est concret : une clé d’hébergement ou d’API dérobée peut ouvrir l’accès à des serveurs, à des données ou à des services payants liés au compte. Si vous ne savez pas où sont rangés les secrets de vos projets, ni comment les renouveler, nous pouvons vous aider à faire le point dans le cadre de notre accompagnement bénévole et gratuit, dans la mesure de nos disponibilités.