Le voleur de secrets wfx a-t-il tourné dans votre dépôt GitHub ?

Le compte GitHub d'un collègue a peut-être poussé un voleur de secrets dans votre dépôt cette semaine, l'a exécuté une fois, puis l'a retiré quelques minutes plus tard. S'il a tourné, chaque secret et chaque rôle cloud que vos workflows peuvent atteindre est entre d'autres mains, et le journal d'exécution qui vous le dirait a disparu.

Aikido Security, qui a signalé la campagne en premier, dénombre 4 837 comptes compromis qui ont ouvert des pull requests de test dans 61 764 dépôts, à partir du 10 novembre. La charge malveillante a tourné dans au moins 1 806 d'entre eux, selon leur décompte.¹ SafeDep a trouvé 8 093 dépôts qui ont reçu des commits malveillants entre le 10 novembre, 12 h 46 UTC, et le 12 novembre, 4 h 36 UTC, et la campagne était encore active quand cette recherche a été lancée.²

Pourquoi vos défenses habituelles ne l'ont pas vu

Ce n'est pas une pull request venue du fork d'un inconnu. Les commits ont pour auteur de vrais utilisateurs du dépôt, avec leur e-mail noreply et sans signature, ce qui pointe vers des tokens volés. Dans 1 343 dépôts, l'auteur n'était pas le propriétaire mais un collaborateur ou un bot.² Les réglages qui protègent contre les forks, comme l'approbation des exécutions de workflow venant de contributeurs externes, n'entrent donc jamais en jeu. L'attaquant a un accès en écriture, le même que votre équipe.

Le schéma est court. D'abord une pull request intitulée docs: dependency audit notes, depuis une branche wfx-docs, pour tester l'accès en écriture. Puis la charge malveillante, sous l'une de ces trois formes : environ 1 500 lignes ajoutées à un workflow existant (ci: refresh build cache), un script plus un hook npm postinstall (chore: add ci helper), ou un nouveau fichier de workflow (chore: add dependency audit workflow). Puis un revert, et l'exécution du workflow est supprimée avec ses journaux.¹ SafeDep a compté 7 309 dépôts avec le workflow injecté et 771 avec le hook npm, qui tourne aussi sur le portable d'un développeur lors d'un npm install.²

Ce qu'il emporte est large : les secrets et variables Actions, le GITHUB_TOKEN, les tokens OIDC, les fichiers d'identifiants pour AWS, Azure, GCP, npm, PyPI et SSH, et les clés d'outils IA. Il utilise ensuite OIDC pour demander des sessions AWS, GCP et Azure.¹ Deux de ses gestes sont faits pour survivre à une rotation. Sur AWS, il peut créer de nouvelles clés d'accès et réécrire la politique de confiance d'un rôle en "Principal": {"AWS": "*"}. Sur Azure, il ajoute des identifiants fédérés nommés wfx-ci-… aux app registrations, pour que le dépôt puisse encore se connecter une fois chaque secret changé.¹

Ce qu'il faut faire lundi

Commencez par les signes. Les deux analyses listent les mêmes : la branche wfx-docs, le titre de la pull request de sondage, et les messages de commit ci-dessus, plus ci: restore et ci: cleanup.² Un revert ne retire pas un commit de l'historique, une recherche les trouve donc toujours :

gh search prs --owner your-org "docs: dependency audit notes" in:title
git log --all --since=2026-11-10 --oneline \
  --grep="ci: refresh build cache" --grep="chore: add ci helper" \
  --grep="chore: add dependency audit workflow" --grep="ci: cleanup"

Ouvrez ensuite l'historique Actions de chaque workflow que l'attaquant a touché. L'absence d'artefact wfx-loot ou de résumé WFX-BEGIN ne veut pas dire que vous êtes à l'abri. Un numéro d'exécution manquant sur le commit de l'attaquant est le signe le plus fiable que la charge a tourné.¹

Si vous trouvez quelque chose, la liste de SafeDep est celle que je suivrais. Une pull request de sondage, à elle seule, veut dire que le compte est compromis. Révoquez les tokens, les autorisations OAuth, les clés SSH et les sessions de ce compte, et activez la 2FA. Changez chaque secret que le dépôt peut lire, y compris les secrets d'environnement et d'organisation. Traitez toute machine qui a lancé npm install sur un commit touché comme compromise.²

Puis le cloud. Dans Entra ID, cherchez des identifiants fédérés nommés wfx-ci-* que vous n'avez pas créés. Dans CloudTrail, cherchez des sessions nommées wfx-* suivies de CreateAccessKey ou UpdateAssumeRolePolicy. Dans GCP, cherchez des appels GenerateAccessToken et SignJwt venant de votre workload identity pool GitHub.²

Ce qui aide ensuite

Quand votre équipe aura le temps, je réduirais ce que « toute personne avec un accès en écriture » peut faire. Mettez les secrets de déploiement dans un environnement GitHub plutôt que dans le dépôt. Un job ne peut pas lire les secrets d'environnement tant qu'un relecteur obligatoire ne l'a pas approuvé, et l'environnement peut être limité à certaines branches.³ Vérifiez d'abord votre offre : sur Free, Pro et Team, les relecteurs obligatoires ne fonctionnent que dans les dépôts publics.³

Faites de même dans le cloud. Le fournisseur compare le sujet du token OIDC aux conditions posées sur le rôle, et un sujet peut nommer l'environnement d'un job, comme repo:octo-org/octo-repo:environment:prod.⁴ Un rôle qui ne fait confiance qu'à ce sujet n'est accessible qu'aux jobs qui passent les règles de cet environnement, pas à un workflow poussé sur n'importe quelle branche.

Enfin, les vérifications obligatoires. Aikido décrit du code qui publie de faux statuts de réussite pour passer les règles de fusion ; SafeDep l'a trouvé désactivé dans les échantillons qu'il a lus.² Dans les deux cas, toute personne ou intégration avec un accès en écriture peut publier un statut. Un ruleset peut n'accepter une vérification obligatoire que d'une GitHub App précise.⁵

Sources

1. Aikido Security, 2026. wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories (en anglais)
2. SafeDep, 2026. wfx: GitHub Actions Credential Stealer Hits 8,000 Repos (en anglais)
3. GitHub Docs. Deployments and environments (en anglais)
4. GitHub Docs. OpenID Connect (en anglais)
5. GitHub Docs. Available rules for rulesets (en anglais)