Depuis le 7 octobre 2026, la campagne GhostAction utilise des comptes GitHub volés pour ajouter un faux workflow « Security Audit » dans des milliers de dépôts, afin d’en voler les secrets. Cette analyse s’adresse aux auditeurs, RSSI et responsables sécurité : déroulé documenté, correspondance avec MITRE ATT&CK, raisons d’une détection difficile, questions d’audit ISO 27001 et pistes de sensibilisation. Notre base est l’article de The Hacker News du 9 octobre 2026, qui cite StepSecurity, Socket et GitGuardian : nous n’avons pas pu lire les billets de ces trois éditeurs en direct.
Pour une lecture orientée dirigeant, voir notre décryptage « GhostAction : un faux audit de sécurité qui vole les clés des projets logiciels ».
Contexte
- Victimes : des mainteneurs open source, dont l’auteur d’un moteur de jeu open source très suivi et un autre développeur open source connu, et, par ricochet, tous ceux qui utilisent ou ont forké leurs dépôts. Plus de 500 comptes GitHub au 9 octobre selon Socket (The Hacker News, 9 octobre 2026).
- Secteur : chaîne d’approvisionnement logicielle (open source, CI/CD).
- Date : vague actuelle depuis le 7 octobre 2026. Une vague précédente a touché 772 dépôts publics (373 utilisateurs et organisations) entre le 31 août et le 30 septembre 2026, selon GitGuardian. La campagne d’origine date de septembre 2025 (3 325 secrets volés).
- Type : attaque de la chaîne d’approvisionnement par vol de secrets, sans exploitation de vulnérabilité.
- Attaquant : non identifié.
Mode opératoire : ce qui est documenté et ce qui ne l’est pas
| Étape | Ce qui est rapporté | Correspondance MITRE ATT&CK (notre lecture) |
|---|---|---|
| Accès initial | L’attaquant obtient le jeton d’accès personnel (PAT) d’un mainteneur, « très probablement » issu de journaux d’infostealers ou de fuites d’identifiants. | T1078 Valid Accounts ; T1195.002 Compromise Software Supply Chain |
| Reconnaissance | Lecture des fichiers de workflow existants pour repérer les noms des secrets du dépôt. | T1083 File and Directory Discovery |
| Implantation | Commit direct sur la branche par défaut, sous l’identité du mainteneur, d’un workflow nommé « Security Audit » ou « GitHub Actions Security ». | T1036 Masquerading |
| Déclenchement | Le workflow se lance à la demande et à chaque push (toutes branches, tous tags), en récupérant tout l’historique git du dépôt. |
T1059.004 Unix Shell |
| Collecte | Ajout des secrets nommés du dépôt, recherche de 13 motifs d’identifiants dans les fichiers et dans tout l’historique, appariement des clés AWS (identifiant et secret). | T1552.001 Credentials In Files |
| Exfiltration | Envoi en HTTP simple, non chiffré, vers une adresse IP contrôlée par l’attaquant et codée en dur. Chaque exécution renvoie aussi un identifiant du dépôt, ce qui donne à l’attaquant une carte des environnements où il peut exécuter du code. | T1048.003 Exfiltration Over Unencrypted Non-C2 Protocol |
La colonne MITRE est une lecture de notre part, elle ne vient pas des sources.
Faits techniques notables
- Vitesse : 318 dépôts modifiés en 16 minutes depuis un seul compte. C’est forcément automatisé.
- Propagation par les forks : les 279 forks d’un des comptes contiennent le workflow. Si les Actions y sont activées, chaque push suivant peut relancer la collecte.
- Cas annexe (août 2026) : dans au moins un dépôt, l’image Docker a été modifiée pour y ajouter un mineur de cryptomonnaie XMRig.
- Pas de paquet piégé, pour l’instant : à la date de l’article, aucune publication malveillante sur npm, PyPI ou un autre registre n’avait été observée avec les jetons volés.
Ce qu’on ne sait pas
L’identité de l’attaquant, l’origine exacte de chaque jeton volé (l’hypothèse des infostealers n’est pas prouvée compte par compte) et l’usage qui sera fait des secrets récupérés. Nous ne spéculons pas sur ces points.
Détection : pourquoi les victimes ne l’ont pas vu
Ce sont des éditeurs spécialisés dans la sécurité de la chaîne logicielle (StepSecurity, Socket, GitGuardian) qui ont repéré et compté les commits malveillants. L’article ne détaille pas leur méthode exacte. Le schéma est très reconnaissable (mêmes noms de fichiers, même destination d’exfiltration, rafales de commits), ce qui le rend visible pour un outil qui surveille les dépôts publics.
Pourquoi les victimes ne l’ont pas vu plus tôt (analyse de notre part) :
- Le commit vient du compte légitime du mainteneur, avec un nom rassurant.
- Rien ne bloque l’ajout d’un workflow si aucune règle de protection de branche n’impose de revue.
- L’exfiltration part des serveurs de GitHub, pas du réseau de l’entreprise : les outils réseau internes ne la voient pas.
Questions d’audit ISO 27001:2022
- A.8.4 et A.8.32 (accès au code source, gestion des changements) : « Les modifications des fichiers de pipeline (
.github/workflows/,.gitlab-ci.yml…) sont-elles soumises à une revue obligatoire par une autre personne, avec protection de la branche principale ? Montrez-moi la règle et un exemple de refus. » - A.5.17 et A.8.5 (informations d’authentification, authentification sécurisée) : « Quelle est la durée de vie maximale et la portée des jetons d’accès personnels (PAT) des développeurs ? Utilisez-vous des jetons à grain fin ou une fédération OIDC pour les pipelines ? Quand a eu lieu la dernière rotation ? »
- A.8.12 et A.8.4 (prévention des fuites de données, accès au code source) : « L’historique complet des dépôts, et pas seulement le code actuel, est-il scanné pour détecter des secrets ? Que faites-vous quand un secret est trouvé : suppression seule, ou révocation et rotation ? »
- A.5.21 et A.5.23 (chaîne d’approvisionnement TIC, services cloud) : « Tenez-vous un inventaire des forks et miroirs privés de projets tiers, et vérifiez-vous les workflows qu’ils héritent avant d’activer les Actions ? »
Pistes de sensibilisation
- Atelier développeurs « Le faux audit » : montrer un workflow de ce type, en version désarmée, et demander aux participants de repérer ce qui cloche (déclenchement à chaque push, récupération de tout l’historique, envoi vers une adresse IP en HTTP). Message : un nom rassurant ne prouve rien.
- Module « Infostealer = clé de la prod » : expliquer le lien entre un logiciel piraté installé sur un poste personnel, le vol d’un jeton GitHub, puis celui d’un pipeline entier. Rappeler les bons réflexes : poste dédié, jetons à durée de vie courte, MFA résistante au phishing sur GitHub.
À lire aussi : notre décryptage pour les dirigeants, « GhostAction : un faux audit de sécurité qui vole les clés des projets logiciels », et le 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.