GitHub Actions : des workflows qui volent les secrets

En octobre 2026, deux campagnes distinctes ont planté des workflows GitHub Actions voleurs de secrets dans des milliers de dépôts. La première, GhostAction, documentée par GitGuardian et Socket, a culminé les 8 et 9 octobre ; selon GitGuardian, GitHub a empêché le workflow malveillant de s'exécuter à partir du 9 octobre. La seconde, Gheist, que Wiz Research suit depuis le 15 septembre et a décrite le 25 octobre, a touché aussi des dépôts privés. Dans les deux cas, les commits ont été poussés avec les propres identifiants des victimes, selon toute apparence volés.

Ce que disent les sources

GitGuardian, sur GhostAction. L'article publié le 7 octobre et mis à jour les 9 et 13 octobre établit d'abord que, du 31 août au 30 septembre 2026, le workflow malveillant a été poussé dans 772 dépôts publics appartenant à 373 utilisateurs et organisations, visant 2 577 secrets. La mise à jour du 13 octobre change d'échelle : « the threat actor targeted more than 30,000 repositories across 3,000 users and orgs », à partir des comptes d'environ 1 900 utilisateurs, avec une tentative d'extraction de 3 174 secrets. GitGuardian ajoute : « GitHub started preventing the malicious workflow from running starting October 9 », si bien que les vagues des 10 et 12 octobre n'ont extrait aucun secret. Autre constat : seulement 124 dépôts, soit 16 %, avaient été réellement nettoyés au 5 octobre. Pour mémoire, la campagne de 2025 avait touché 817 dépôts chez 327 utilisateurs et exfiltré au moins 3 325 secrets.

Socket, sur la même campagne. Le 9 octobre, Socket décrivait une rafale du 8 octobre : 2 comptes de mainteneurs compromis, 346 dépôts touchés. Sa mise à jour du même jour fait état de plus de 500 comptes ayant poussé le workflow dans des dizaines de milliers de dépôts depuis le 7 octobre, dont plusieurs appartenant à des organisations. Socket note que cette variante ne se limite plus aux secrets des Actions : elle cherche aussi des identifiants infonuagiques et de services d'IA dans le code et l'historique du dépôt.

Les chiffres ne concordent pas. GitGuardian parle d'environ 1 900 comptes, Socket de plus de 500 au 9 octobre. Les deux décomptes ont été publiés à des dates différentes, le 9 et le 13 octobre, chacun à partir des données de sa firme ; nous les donnons donc tels quels.

Wiz Research, sur Gheist. Le 25 octobre, Wiz décrit une campagne différente, qu'il distingue expressément de GhostAction : « We have recovered more than 13,500 planted branches from more than 850 compromised accounts », des projets personnels jusqu'aux dépôts privés d'entreprises. Les identifiants retracés viennent vraisemblablement de journaux de logiciels voleurs d'informations et de jetons exposés lors de compromissions antérieures de la chaîne logicielle.

GitHub. Le 28 juillet 2026, GitHub annonçait que les exécutions potentiellement malveillantes attendent l'approbation d'un collaborateur ayant l'accès en écriture. Mais « this protection currently applies to public repositories on github.com only ». Wiz confirme que la retenue a fonctionné dans les dépôts publics, et qu'elle « doesn't apply to private repositories or GitHub Enterprise Server », où il a vu des exécutions aboutir.

Pourquoi ça compte

Un secret de pipeline est une identité. Il publie des paquets, déploie en production, lit un coffre ou crée des ressources infonuagiques. Le recensement de GitGuardian le montre : clés SSH et identifiants de serveurs de déploiement, identifiants Azure, registres de conteneurs, bases de données, clés AWS. Qui contrôle le workflow contrôle tout ce que ces secrets ouvrent.

La seconde leçon porte sur la durée de vie. GitGuardian observe que certaines victimes de 2026 l'avaient déjà été en 2025, probablement parce que d'anciens identifiants n'avaient jamais été renouvelés. Un jeton personnel volé sur un poste et toujours valide a suffi à pousser du code dans chaque dépôt qu'il pouvait atteindre.

Enfin, les jetons à courte durée de vie ne règlent pas tout seuls le problème. Wiz a vu les workflows des organisations elles-mêmes obtenir des rôles AWS par OIDC depuis les branches implantées. L'OIDC supprime le secret stocké, mais la relation de confiance doit encore être limitée aux branches et aux environnements protégés.

Ce que nous en pensons chez Sentrix

1. Inventorier les secrets de CI comme des identités. Chaque secret a un propriétaire, une portée, une date d'expiration et une liste de dépôts qui peuvent le lire. C'est la démarche décrite dans notre article sur les identités non humaines.
2. Passer à des identifiants à courte durée de vie. L'OIDC entre GitHub et le fournisseur infonuagique remplace les clés stockées, à condition de limiter la confiance aux branches protégées et aux environnements avec réviseurs obligatoires, comme le recommande Wiz. Notre service sécurité infonuagique couvre ces relations de confiance.
3. Retirer les jetons personnels des automatisations. Wiz recommande de préférer les GitHub Apps ou des jetons à granularité fine et à courte durée. Ce sont des jetons volés, en partie retracés par Wiz jusqu'à des journaux de logiciels voleurs d'informations, qui ont servi ici. Notre service identité et accès aide à faire ce ménage.
4. Réviser toute modification de workflow. Un fichier ajouté dans le répertoire des workflows devrait exiger une revue par un responsable désigné, même poussé par un compte légitime, et une alerte devrait signaler toute nouvelle branche qui en ajoute un.
5. Après un incident, révoquer avant de tourner. Révoquer le jeton qui a poussé le commit, faire tourner chaque secret que le dépôt pouvait atteindre, vérifier l'historique de publication des paquets et traiter tout exécuteur auto-hébergé touché comme compromis. Les indicateurs détaillés se trouvent dans les publications de GitGuardian, Socket et Wiz.
6. Demander la même chose à vos fournisseurs. Un fournisseur dont le pipeline est compromis publie du code compromis. Comment il protège ses secrets de CI fait partie des questions de notre article sur le SBOM et ce qu'il faut demander à un fournisseur, et de l'évaluation des risques tiers.

La prochaine étape

Listez aujourd'hui les secrets que vos workflows peuvent lire, avec, pour chacun, ce qu'il ouvre, sa date d'expiration et la dernière fois qu'il a été renouvelé. Les lignes sans date sont votre priorité de la semaine. Si vous voulez faire cet exercice avec nous, contactez-nous.