La campagne Gheist utilise des jetons GitHub volés pour récolter massivement des secrets de dépôts

La société de sécurité cloud Wiz suit une campagne d'attaque automatisée, baptisée Gheist, qui utilise des jetons d'accès GitHub volés pour extraire systématiquement des secrets de dépôts privés et d'environnements GitHub d'entreprise. Wiz a récupéré plus de 13 500 branches malveillantes plantées sur plus de 850 comptes compromis depuis le début du suivi de la campagne le 15 septembre 2026, et au 24 octobre, l'opération était toujours active et en évolution.

Le nom vient de la chaîne user agent «gheist» que l'outil automatisé des attaquants envoie avec chaque requête à l'API GitHub, selon le rapport publié le 26 octobre par The Hacker News.

Comment l'attaque extrait les secrets sans serveur de commande

Le mécanisme de Gheist est conçu pour ne rien laisser aux attaquants à bloquer. En utilisant un jeton volé, l'outil énumère chaque dépôt auquel ce jeton peut accéder. Pour chacun, il crée une branche nommée ci-sync- suivie de six caractères aléatoires, puis commite un seul fichier — .github/workflows/sync-check.yml — avec le message de commit anodin «ci: sync config». Le commit reste non signé.

Pousser cette branche déclenche automatiquement le workflow, qui imprime simplement chaque variable d'environnement et secret que le job a la permission de lire. Pour contourner le masquage automatique des journaux de GitHub pour les modèles de secrets connus, l'outil encode la sortie en base32 avant de l'imprimer. L'attaquant télécharge ensuite le journal résultant via l'API GitHub elle-même — ce qui signifie que les données volées n'ont jamais besoin de sortir via un serveur externe qu'un défenseur pourrait détecter ou bloquer — et supprime l'exécution du workflow quelques secondes après l'avoir récupéré.

Échelle et conséquences réelles

Wiz n'a pas révélé combien d'organisations ont effectivement eu des secrets exposés, mais confirme que la campagne a réussi à la fois contre des dépôts privés et des déploiements complets de GitHub Enterprise Server, pas seulement des projets personnels publics.

La protection existante de GitHub ne couvre que la moitié du problème

Depuis le 28 juillet, GitHub exige qu'un collaborateur disposant d'un accès en écriture approuve manuellement les exécutions de workflow signalées comme suspectes — un changement dont Wiz a confirmé qu'il avait stoppé toutes les tentatives de Gheist testées contre des dépôts publics. Cependant, cette exigence d'approbation ne s'étend pas aux dépôts privés ni à GitHub Enterprise Server, soit exactement là où Gheist a enregistré ses succès documentés.

Réponse recommandée

Wiz recommande aux organisations de rechercher dans leurs journaux d'audit les branches correspondant au modèle de nommage ci-sync- et d'examiner toute assomption de rôle OIDC liée à ces branches. Tout secret accessible depuis un dépôt affecté doit être considéré comme compromis et immédiatement renouvelé.