Gheist : jetons GitHub volés, secrets dans les logs

Ce qui se passe

Wiz suit depuis le 15 septembre 2026 une campagne qu'il a baptisée Gheist, d'après l'agent utilisateur gheist que l'outil des attaquants envoie à l'API de GitHub. Le principe : avec un jeton volé qui a l'accès en écriture, pousser un workflow qui affiche les secrets du dépôt dans les journaux GitHub Actions, les télécharger, puis supprimer l'exécution.

Wiz a retrouvé plus de 13 500 branches plantées, sur plus de 850 comptes compromis, des projets personnels aux dépôts privés d'entreprises. La campagne tournait encore le 24 octobre, et environ deux tiers des comptes n'étaient plus disponibles sur GitHub, ce qui laisse penser à une intervention de la plateforme.

Le mécanisme

Pour chaque dépôt que le jeton atteint, l'outil :

crée une branche nommée ci-sync- suivie de six caractères aléatoires ;
y commite un seul fichier, .github/workflows/sync-check.yml, avec le message ci: sync config (commit non signé, au nom du propriétaire du jeton) ;
laisse le push déclencher le workflow, qui imprime l'environnement du job et tous les secrets qu'il peut lire, encodés en base32 ;
télécharge le journal par l'API, puis supprime l'exécution quelques secondes plus tard.

L'encodage compte : GitHub masque les secrets dans les journaux, mais pas de façon garantie une fois la valeur transformée. Le texte base32 ne ressemble plus au secret et s'affiche en clair. Le bloc permissions vide du workflow limite le GITHUB_TOKEN, dont les attaquants n'ont pas besoin ; il n'empêche pas de lire les secrets. Une version lance aussi un job par environnement de déploiement, donc les secrets de production y passent.

Les secrets sortent par GitHub lui-même : aucun serveur d'attaquant, aucune connexion sortante à bloquer.

Ce qui limite, et ce qui ne limite pas

Depuis le 28 juillet, GitHub suspend les exécutions jugées malveillantes jusqu'à l'accord d'un collaborateur en écriture. Cette protection ne vaut que pour les dépôts publics de github.com : ni les dépôts privés, ni GitHub Enterprise Server. Toutes les exécutions publiques de Gheist que Wiz a vérifiées attendaient cette approbation.
Dans les organisations touchées, l'outil a enchaîné en quelques minutes les jetons de plusieurs utilisateurs et comptes d'automatisation, cloné des dépôts privés avant de planter le workflow. Des heures après, des identifiants cloud de la même organisation ont servi à énumérer AWS Secrets Manager ; Wiz ne dit pas d'où ils venaient.
Vers le 19 octobre, une version a ajouté un second job visant les runners auto-hébergés, qui cherche 31 types de jetons. Wiz le juge défaillant et ne rapporte aucune exécution réussie.
Les jetons proviennent notamment de journaux de voleurs d'identifiants et d'anciennes compromissions, comme celle du scanneur Trivy en mars. Wiz range Gheist à part de GhostAction, qui utilise d'autres fichiers de workflow.

Comment vérifier ses dépôts

Cherchez les branches ci-sync- + six caractères dont la seule modification est le fichier .github/workflows/sync-check.yml, message ci: sync config.
Dans les journaux d'audit GitHub : exécutions sur des branches ci-sync-* supprimées moins d'une minute après leur fin, et toute activité de l'agent utilisateur gheist.
Si vos workflows se connectent au cloud en OIDC, cherchez dans les journaux du fournisseur des prises de rôle dont le sujet contient une branche ci-sync-. Par défaut, le sujet porte le nom de branche seulement si le job n'utilise pas d'environnement de déploiement.
Sur les runners auto-hébergés : fichiers .gdmp_pat, .gdmp_patg, .gdmp_sweep et chaîne gdmp-pivot dans les journaux de job.

Supprimer la branche ou l'exécution n'annule pas l'exposition. Faites tourner tous les secrets que le dépôt pouvait lire et révoquez le jeton qui a poussé la branche.

Source : The Hacker News, 26 octobre 2026. Source en anglais. Analyse d'origine : Wiz.