Gheist : des jetons GitHub volés pour vider les secrets de vos pipelines

Vos pipelines d'intégration et de déploiement continus (CI/CD) contiennent souvent les clés les plus sensibles de l'entreprise : accès au cloud, mots de passe de bases de production, jetons de publication. Le 25 octobre 2026, les chercheurs de Wiz ont publié l'analyse d'une campagne baptisée Gheist, qui s'en prend précisément à ces secrets, en passant par GitHub lui-même.

Ce qui s'est passé

Wiz suit cette campagne depuis le 15 septembre. Elle était encore active le 24 octobre. Les chercheurs ont retrouvé plus de 13 500 branches piégées créées depuis plus de 850 comptes GitHub compromis, de projets personnels jusqu'à des dépôts privés d'entreprises.

Le point de départ, ce sont des jetons GitHub volés. Wiz les relie à des journaux de logiciels espions (infostealers) installés sur des postes de développeurs, et à des jetons exposés lors d'attaques précédentes de la chaîne d'approvisionnement. Un simple jeton avec un droit d'écriture sur un dépôt suffit : ce droit permet de lire tous les secrets configurés dans ce dépôt.

Le mode opératoire, étape par étape

1. Pour chaque dépôt accessible avec le jeton volé, l'outil crée une branche nommée ci-sync- suivie de six caractères aléatoires.
2. Il y ajoute un seul fichier, .github/workflows/sync-check.yml. L'envoi de ce fichier déclenche automatiquement le workflow.
3. Le workflow affiche dans le journal d'exécution les variables d'environnement et les secrets qu'il peut lire, encodés en base32.
4. L'outil télécharge le journal par l'API de GitHub, puis supprime l'exécution quelques secondes plus tard.

Deux détails rendent l'attaque efficace. D'abord, le masquage des secrets ne fonctionne plus : GitHub masque les secrets dans les journaux, mais une valeur encodée en base32 ne ressemble plus au secret d'origine et apparaît en clair. Ensuite, il n'y a aucun serveur pirate à bloquer : les données sortent par GitHub lui-même.

Certaines versions lancent aussi une tâche pour chaque environnement de déploiement. Les secrets propres à un environnement, souvent ceux de la production, sont alors exposés eux aussi. Dans des cas observés en entreprise, des identifiants cloud de la même organisation ont servi quelques heures plus tard à explorer AWS Secrets Manager.

Comment Gheist vide les secrets d'un dépôt

Ce que GitHub a déjà fait, et ses limites

Depuis le 28 juillet, GitHub met en attente les exécutions de workflow jugées suspectes, jusqu'à leur validation par un collaborateur ayant le droit d'écriture. Toutes les exécutions Gheist vérifiées par Wiz sur des dépôts publics ont été bloquées.

Mais cette protection ne s'applique qu'aux dépôts publics de github.com. Les dépôts privés et GitHub Enterprise Server n'en bénéficient pas. Or ce sont justement eux qui hébergent le code et les secrets des entreprises.

Vérifier si vous êtes touché

• Recherchez dans vos organisations des branches dont le nom commence par ci-sync- et qui n'ajoutent que le fichier sync-check.yml.
• Dans les journaux d'audit, cherchez des exécutions supprimées moins d'une minute après leur lancement, et l'agent utilisateur gheist.
• Si vos workflows accèdent au cloud par OIDC, vérifiez les connexions de rôles dont le sujet contient une branche ci-sync-.
• Sur les runners auto-hébergés, cherchez des fichiers .gdmp_* et la chaîne gdmp-pivot.

Si vous trouvez des traces

• Changez tous les secrets auxquels le dépôt avait accès, sans exception.
• Révoquez les jetons qui ont poussé les commits, et vérifiez les postes de leurs propriétaires : le vol vient souvent d'un logiciel espion.
• Considérez comme compromis tout runner auto-hébergé qui a exécuté une branche ci-sync-, ainsi que le rôle cloud qu'il utilisait.
• N'approuvez jamais une exécution sync-check mise en attente.

Durcir vos pipelines

• Protéger les environnements de production : exiger une validation par un responsable avant qu'un workflow puisse lire leurs secrets.
• Restreindre la confiance OIDC aux branches protégées ou aux environnements validés, pour qu'une branche quelconque ne puisse pas obtenir un rôle cloud.
• Remplacer les jetons personnels par des GitHub Apps ou des jetons à granularité fine et de courte durée.
• Utiliser des runners éphémères, recréés à chaque exécution, sans accès au socket Docker ni aux métadonnées du cloud.
• Protéger les postes des développeurs avec un EDR : c'est là que les jetons sont volés.
• Préférer des identifiants temporaires aux secrets permanents stockés dans les dépôts.

Ce qu'il faut retenir

Un dépôt de code n'est pas qu'un dépôt de code : c'est souvent la clé de la production. Le droit d'écriture sur un dépôt doit être traité comme un accès à privilèges, avec la même rigueur que les comptes d'administration.

Sources

• The Hacker News : Gheist et les jetons GitHub volés
• Unosecur : chronologie des incidents d'octobre 2026

---

BigMind aide les entreprises à auditer leurs pipelines CI/CD, à sécuriser leurs secrets et à protéger les postes de leurs équipes techniques. Parlons de votre situation.