Introduction
En moins de 48 heures, la troisième vague de la campagne GhostAction a compromis plus de 500 comptes GitHub de mainteneurs pour injecter un workflow malveillant dans des dizaines de milliers de dépôts. La date du 8 octobre 2026 restera comme le moment où cette campagne persistante a franchi un cap : au-delà des secrets CI/CD habituels, elle s'attaque désormais à l'intégralité de l'historique git des projets ciblés.
La mécanique de l'attaque
Le fichier déposé se nomme .github/workflows/security-audit.yml — un nom intentionnellement rassurant, conçu pour imiter les pratiques de sécurité légitimes. Les commits associés portent des messages tels que « Add security audit workflow » ou « Update security audit workflow », calibrés pour se fondre dans la masse des contributions quotidiennes.
Une fois le workflow en place, il s'exécute sur toute poussée de code, sans filtre de branche. Sa première action est de cartographier les secrets GitHub Actions existants du dépôt — une reconnaissance automatisée qui trahit une orchestration outillée, pas une intervention manuelle. Il récupère ensuite la totalité de l'historique git grâce au paramètre fetch-depth: 0, une option qui rapatrie chaque commit sur chaque branche, y compris les branches stales et les références orphelines. L'ensemble des données collectées est exfiltré en clair vers une adresse IP codée en dur via une simple requête HTTP POST.
Quand l'historique git devient surface d'attaque
Les vagues précédentes de GhostAction se limitaient aux secrets déclarés dans GitHub Actions. La vague d'octobre 2026 maintient cette capacité et y ajoute une nouveauté critique : un balayage par expressions régulières de l'ensemble du contenu versionné, arbre de travail et historique complet confondus.
Les patterns recherchés couvrent treize catégories de credentials : clés d'accès AWS longues et temporaires (STS), clés secrètes AWS, tokens de session, clés d'API Anthropic, OpenAI et OpenRouter, tokens GitHub et GitLab, clés Google/Firebase/GCP, tokens Slack et clés SendGrid. La subtilité technique réside dans la gestion des clés AWS : lorsqu'un identifiant de clé est détecté, le workflow capture les deux lignes précédentes et suivantes pour reconstituer la paire identifiant/secret, qu'elle se trouve dans un fichier .env, un bloc Terraform ou un fichier de credentials AWS. La raison est simple : ces credentials, les mainteneurs les croient souvent définitivement effacés, alors qu'ils persistent dans l'historique git.
Socket Research confirme l'exfiltration réussie de 3 325 secrets. Parmi les dépôts touchés lors du burst du 8 octobre figurent kitao/pyxel (18 420 étoiles) et uber/athenadriver, tous deux compromis via des comptes mainteneurs dont les accès avaient été détournés.
Les mesures immédiates pour vos équipes
La première urgence est la rotation de toutes les credentials potentiellement exposées — non pas uniquement celles du dernier commit, mais toute clé ayant transité dans l'historique git depuis la création du dépôt. La commande git log -p --all permet de retrouver chaque occurrence, y compris dans les branches supprimées.
Pour les clés AWS exposées, l'audit CloudTrail sur la fenêtre temporelle de l'exposition est indispensable avant toute révocation : une clé piratée laisse des traces d'usage qu'il faut identifier pour évaluer l'étendue réelle de la compromission.
Sur le plan préventif, trois mesures s'imposent : activer le secret scanning avec push protection sur tous les dépôts GitHub, restreindre les permissions d'écriture directe sur les branches par défaut, et surveiller l'apparition de fichiers .github/workflows/security-audit.yml dans vos alertes de dépôts. L'indicateur réseau à bloquer immédiatement : 193.32.204[.]199.
GhostAction illustre une tendance de fond : les pipelines CI/CD sont devenus la voie d'entrée de choix pour les campagnes de vol de credentials à grande échelle. La surface d'attaque ne se limite plus à ce que vos workflows exposent aujourd'hui — elle englobe l'ensemble de ce que votre base de code a jamais contenu.