GhostAction : un faux audit de sécurité qui vole les clés des projets logiciels

Depuis le 7 octobre, des attaquants utilisent des comptes GitHub volés pour ajouter, dans des milliers de projets logiciels, une tâche automatique baptisée « Security Audit ». Elle ne contrôle rien : elle récupère les clés d’accès du projet et les envoie à l’attaquant. Aucune faille logicielle n’est en jeu, seulement des accès volés et la confiance qu’on accorde aux automatisations.

Ce qui s’est passé

GitHub est la plateforme où de très nombreux développeurs, entreprises et projets open source stockent leur code. Elle propose GitHub Actions, un service qui lance automatiquement des tâches (tests, mise en ligne…) à chaque modification du code. Ces tâches, appelées « workflows », ont souvent accès aux secrets du projet : clés d’accès au cloud, jetons de publication, clés d’API (des codes qui ouvrent l’accès à un service en ligne).

Selon The Hacker News, qui s’appuie sur les recherches des sociétés StepSecurity, Socket et GitGuardian, la campagne GhostAction, repérée une première fois en septembre 2025, a repris (The Hacker News, 9 octobre 2026) :

  • le compte de l’auteur d’un moteur de jeu open source très suivi a servi à pousser le faux workflow dans 27 projets ;
  • huit heures plus tard, le compte d’un autre développeur open source connu l’a poussé dans 318 projets en 16 minutes, ce qui suppose un outil automatique ;
  • au 9 octobre, Socket comptait plus de 500 comptes GitHub ayant ajouté ce workflow depuis le 7 octobre, dans des dizaines de milliers de projets.

Une vague précédente avait déjà touché 772 projets publics entre le 31 août et le 30 septembre 2026, selon GitGuardian.

Comment l’attaque a fonctionné

  1. Le vol d’accès. L’attaquant récupère le jeton d’accès (une sorte de mot de passe technique) d’un développeur. Selon les chercheurs, ces jetons viennent « très probablement » de logiciels voleurs d’identifiants (infostealers) installés sur des ordinateurs, ou de fuites de données. Ce n’est pas prouvé compte par compte.
  2. Le dépôt du piège. Avec ce jeton, il ajoute directement dans le projet un workflow au nom rassurant, « Security Audit » ou « GitHub Actions Security ». Pour GitHub, c’est une modification normale faite par le vrai développeur.
  3. La collecte. À chaque modification du code, le workflow se lance. Il récupère les secrets du projet et cherche 13 types d’identifiants (clés cloud, clés de services d’IA, jetons…) dans les fichiers et dans tout l’historique du projet, y compris des versions anciennes.
  4. L’envoi. Il transmet le tout, sans chiffrement, à un serveur de l’attaquant.

Trois points aggravent la situation. Un secret supprimé d’un fichier il y a longtemps reste dans l’historique, et le workflow va l’y chercher. Le piège est recopié dans les copies du projet (les « forks »), ce qui étend le risque aux dépôts privés, là où les vrais secrets sont stockés. Enfin, l’envoi part des serveurs de GitHub et non du réseau de l’entreprise : les outils de surveillance internes ne le voient pas.

Ce qu’on ne sait pas encore

Aucun auteur n’est identifié. À la date de l’article de The Hacker News, aucune publication de logiciel piégé à l’aide des clés volées n’avait été observée.

Ce que ça change pour une PME

Même sans équipe de développement, beaucoup de PME font développer leur site, leur application ou leurs outils par un prestataire qui utilise GitHub. Vos clés d’accès (hébergement, paiement, messagerie) peuvent donc s’y trouver.

  1. Posez la question à votre équipe ou à votre prestataire : vos projets sont-ils sur GitHub, et un workflow « Security Audit » ou « GitHub Actions Security » y a-t-il été ajouté depuis fin août ? Si oui, tous les secrets du projet doivent être considérés comme volés : on les révoque et on les remplace, supprimer le fichier ne suffit pas.
  2. Exigez une relecture par une deuxième personne pour toute modification du code principal, y compris les fichiers d’automatisation.
  3. Préférez des accès à durée de vie courte et limités au strict nécessaire, et activez la double authentification sur tous les comptes GitHub.
  4. Protégez les postes des développeurs : un ordinateur infecté par un voleur d’identifiants, souvent via un logiciel piraté ou une extension douteuse, peut suffire à ouvrir la porte à vos systèmes en production.

Cet article prolonge notre bulletin de veille du 11 octobre 2026.

Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.