Voleur de secrets wfx sur GitHub Actions : comment le traquer quand la rotation des clés ne suffit pas

Le 10 novembre 2026, une campagne de vol d'identifiants que les chercheurs appellent wfx (également signalée sous les noms wfx-loot et WFX Phantom) a commencé à injecter à grande échelle des voleurs de secrets CI dans des dépôts GitHub. Les données de SafeDep montrent des commits malveillants arrivant à partir de 12:46 UTC le 10 novembre.

Le réflexe consiste à tout renouveler. Vous devez effectuer la rotation, mais la rotation seule peut laisser à l'attaquant une voie de retour fonctionnelle, via des paramètres de confiance qu'aucun secret ne contrôle.

Ce qu'est wfx, et pourquoi cela ressemble à un travail de développeur ordinaire

Aucune faille de GitHub Actions n'est au cœur de cette affaire. L'analyse de StepSecurity indique que l'attaquant détient des jetons valides de vrais comptes de développeurs et de bots, et qu'il les utilise comme le ferait un développeur, en ouvrant des pull requests et en poussant des commits. Rien dans votre fil d'activité ne ressemble à un exploit. On dirait un collègue, ou un bot, en train d'effectuer un travail de routine.

L'ampleur est considérable. Aikido rapporte que 4,837 comptes compromis ont ouvert des pull requests de sondage dans 61,764 dépôts, et qu'au moins 1,835 dépôts ont exécuté la charge utile et vu leurs identifiants exfiltrés. SafeDep a compté de manière indépendante 61,879 pull requests de sondage dans 61,734 dépôts, provenant de 4,833 comptes, dont 91% étaient encore ouvertes. StepSecurity signalait plus de 63,000 pull requests de sondage à 07:40 UTC le 12 novembre, dont environ 90% encore ouvertes, et de nouvelles apparaissaient toutes les quelques minutes.

Pourquoi les chiffres des chercheurs diffèrent

Chaque décompte mesure quelque chose de différent, à un moment différent : les chiffres se complètent donc plutôt qu'ils ne se contredisent. SafeDep a compté 8,093 dépôts ayant reçu des commits malveillants entre 12:46 UTC le 10 novembre et 04:36 UTC le 12 novembre, et la campagne était toujours active au moment de cette recherche. SecurityWeek note que le nombre de commits n'indique pas nécessairement une exécution réussie, tandis que le chiffre d'Aikido, plus de 1,800 dépôts, reflète des signes montrant que le voleur s'est réellement exécuté. Le jeu de données propre à GitGuardian contient 28,500 correctifs de charge utile provenant de 2,367 comptes, répartis sur 17,715 dépôts.

Une pull request de sondage signifie qu'un compte a tenté d'entrer, un commit malveillant signifie qu'il disposait d'un accès en écriture, et une exécution confirmée signifie que des secrets sont probablement sortis. Le cas qui vous concerne parmi ces trois doit orienter la suite, et seuls vos propres journaux peuvent vous dire lequel.

Comment le voleur atteint les secrets CI

Les pull requests de sondage testent l'accès

Nous vous conseillons de considérer toute pull request de sondage comme le signe que quelqu'un a testé ce qu'un jeton volé permettait d'atteindre. Help Net Security rapporte que 10,431 de ces pull requests de sondage visaient des dépôts dont le compte n'était pas propriétaire, atteints grâce à un accès de collaborateur ou d'organisation. Un seul jeton volé expose donc tous les projets sur lesquels son titulaire peut écrire, quel que soit le propriétaire du dépôt.

L'injection dans les workflows a été la principale voie de diffusion

Une fois l'accès confirmé, l'étape suivante habituelle consiste à injecter le voleur dans un workflow existant. StepSecurity a trouvé plus de 21,000 commits portant le message ci: refresh build cache entre le 10 et le 12 novembre. SafeDep a trouvé 1,343 dépôts où l'auteur du commit malveillant était un compte autre que le propriétaire, par exemple un collaborateur ou un bot. Ce second chiffre est important pour délimiter le périmètre : lorsque le jeton d'un collaborateur ou d'un bot est volé, le commit malveillant arrive dans votre dépôt sous son nom, et une revue qui ne porte que sur l'activité du propriétaire passera à côté.

Le blocage de GitHub a arrêté une variante, mais pas l'autre

GitGuardian rapporte que toutes les exécutions de charge utile de novembre qu'il pouvait encore observer à partir de modifications de fichiers de workflow ont été placées en action_required et n'ont jamais démarré. La variante par hook npm, elle, n'a pas été bloquée : sur un échantillon de 19 dépôts où le script s'est exécuté, 18 ont signalé une exfiltration réussie. Selon notre lecture, un hook de dépendance s'appuie sur un workflow qui existe déjà au lieu d'arriver sous la forme d'une modification de fichier de workflow, si bien qu'un processus de revue centré uniquement sur les fichiers de workflow risque de ne pas le repérer. Pour les défenseurs, cela signifie examiner les manifestes de dépendances avec la même méfiance que les fichiers de workflow.

Autres voies : GitHub Apps et exfiltration via Telegram

Tous les jetons volés n'étaient pas des jetons personnels. StepSecurity a constaté que 173 pull requests de sondage, ouvertes depuis 19 comptes, avaient été créées via la GitHub App de Fly.io (app ID 34557). Votre périmètre doit couvrir les autorisations OAuth et les installations de GitHub Apps, en plus des jetons d'accès personnels. L'exfiltration a elle aussi évolué. Les premières copies envoyaient les données vers des adresses IP précises, et StepSecurity indique qu'avec le passage à Telegram, les listes de blocage construites à partir des adresses IP du 10 novembre ne détectent pas les copies les plus récentes. Une correspondance avec ces adresses mérite toujours une enquête, mais un résultat vide sur la liste de blocage ne vous dit pas grand-chose sur une éventuelle fuite de données.

Pourquoi la rotation des clés ne met pas fin à la compromission

GitHub a conçu son intégration OIDC pour limiter les dégâts. La documentation de GitHub explique que le fournisseur cloud émet un jeton d'accès de courte durée, valable pour une seule tâche, qui expire ensuite. Un jeton OIDC volé n'a donc pas grande valeur à lui seul : un attaquant qui veut rester doit transformer cette courte fenêtre en une relation de confiance durable.

Les identifiants d'identité fédérée Entra comme porte dérobée

Sur Azure, l'identifiant d'identité fédérée est l'outil tout désigné pour cela. Microsoft le décrit comme un identifiant qui crée une relation de confiance entre une application et un fournisseur d'identité externe. Aikido rapporte qu'une fois cette porte dérobée en place, n'importe quel workflow de ce dépôt peut s'authentifier auprès d'Azure sans secret stocké, même après la rotation de tous les jetons.

Des politiques de confiance AWS trop permissives pour l'OIDC de GitHub

Sur AWS, l'exposition se situe dans les politiques de confiance des rôles. AWS avertit que si vous ne limitez pas la clé de condition token.actions.githubusercontent.com:sub à une organisation ou à un dépôt précis, des GitHub Actions provenant d'organisations ou de dépôts hors de votre contrôle peuvent assumer les rôles associés au fournisseur d'identité GitHub de votre compte.

La rotation remplace les secrets volés, mais elle laisse la configuration de confiance exactement telle que l'attaquant l'a définie. C'est le point que la direction a le plus besoin d'entendre avant de valider une réponse comme terminée.

La traque de wfx : l'ordre des opérations

Étape 1 : délimiter les identités

Dressez la liste de tous les comptes humains, bots et GitHub Apps disposant d'un accès en écriture dans vos organisations, collaborateurs externes compris. Tout compte qui apparaît dans des pull requests de sondage présente un risque élevé. Signalez aussi les comptes touchés par la vague GhostAction d'octobre : Aikido a constaté que ces comptes avaient nettement plus de risques que la moyenne d'être touchés par wfx, et GitGuardian a découvert que 431 comptes wfx, soit environ 20%, avaient déjà été compromis lors de GhostAction.

Étape 2 : fouiller GitHub

Fouillez tous les dépôts sur lesquels vos comptes peuvent écrire, et pas seulement ceux dont vous êtes propriétaire. Recherchez :

• Des pull requests de sondage, ouvertes ou fermées, provenant de comptes inattendus.
• Des commits intitulés ci: refresh build cache, sur la branche par défaut comme sur les autres branches.
• Des modifications de fichiers sous .github/workflows/ depuis le 10 novembre.
• Des modifications des scripts de cycle de vie de package.json, tels que preinstall, install et postinstall.

Étape 3 : vérifier l'historique des exécutions de workflows

Nous vous conseillons de comparer l'historique des exécutions de workflows avec le journal d'audit de votre organisation, et de noter toute exécution supprimée, qui l'a supprimée et quand. Lorsque l'exécution est confirmée, partez du principe que tous les secrets accessibles à cette tâche ont été exposés.

Étape 4 : examiner les identifiants fédérés Microsoft Entra

Nous vous conseillons de lister les identifiants d'identité fédérée de chaque inscription d'application et de chaque identité managée affectée par l'utilisateur. Enquêtez sur tout ce que vous n'avez pas créé, sur tout émetteur ou sujet inattendu, et sur tout sujet pointant vers un dépôt, une branche ou un environnement que vous ne reconnaissez pas. Nous n'avons trouvé aucune source fournisseur identifiée confirmant un schéma de nommage précis pour les identifiants malveillants. Considérez donc les noms qui circulent de manière informelle, comme wfx-ci-*, comme des pistes non vérifiées plutôt que comme des indicateurs, et n'oubliez pas qu'un identifiant renommé ne correspondrait de toute façon pas. Nous vous conseillons d'utiliser vos journaux d'audit pour établir quand chaque identifiant a été ajouté et par qui, ce qui constitue selon nous un test plus fiable que n'importe quel nom.

Étape 5 : examiner les politiques de confiance AWS

Examinez chaque rôle IAM qui fait confiance au fournisseur OIDC de GitHub. La condition sub doit être restreinte à des organisations et à des dépôts précis, et idéalement à des branches ou à des environnements précis. Une condition bien délimitée ressemble à ceci :

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"
  }
}

Nous vous conseillons ensuite d'examiner votre piste d'audit cloud à la recherche de modifications récentes des politiques de confiance, de rôles nouvellement créés et de prises de rôle depuis des dépôts inattendus.

Étape 6 : examiner l'utilisation des fournisseurs d'IA

Pour chaque clé OpenAI, Anthropic et Gemini accessible depuis la CI, examinez l'utilisation et la facturation. Vous recherchez des dépenses, des modèles, des régions ou des schémas de requêtes qui ne correspondent pas à vos charges de travail. Pour les questions plus générales à se poser lorsque des clés d'IA ont pu être détournées, notre liste de contrôle des risques liés aux fournisseurs d'inférence peut vous aider.

Étape 7 : préserver les preuves avant de modifier quoi que ce soit

Exportez les journaux d'audit, les enregistrements d'exécution des workflows, les métadonnées des pull requests et des commits, les entrées d'audit Entra et les événements CloudTrail avant de commencer le nettoyage. Si vous supprimez une pull request ou un identifiant malveillant sans en conserver de trace, vous perdez la chronologie dont vous aurez besoin pour délimiter le périmètre, établir vos rapports et effectuer toute notification réglementaire.

Confinement et rétablissement, dans l'ordre

L'ordre compte, car un secret renouvelé peut être récupéré à nouveau par une voie de confiance toujours active : tant qu'un identifiant fédéré malveillant ou une politique de confiance trop permissive fonctionne, un workflow contrôlé par l'attaquant peut atteindre les nouvelles valeurs aussi facilement que les anciennes. Voici l'ordre que nous suggérons :

1. Supprimer d'abord l'accès permanent de l'attaquant. Supprimez les identifiants fédérés malveillants et resserrez les politiques de confiance AWS avant la rotation, ou en même temps.
2. Révoquer l'accès GitHub. Révoquez les jetons d'accès personnels, les autorisations OAuth et les installations de GitHub Apps compromis, y compris les applications tierces comme celle identifiée par StepSecurity.
3. Renouveler les secrets. Cela comprend les secrets Actions, les clés cloud, les jetons de registres de paquets et les clés des fournisseurs d'IA.
4. Nettoyer le code. Fermez ou supprimez les pull requests de sondage et annulez les modifications injectées dans les workflows et les paquets, sur la branche par défaut comme sur les autres. Toute pull request de sondage laissée ouverte dans une file de revue donne à un mainteneur l'occasion de la fusionner par erreur.
5. Terminer le nettoyage de GhostAction. Aikido a trouvé plus de 100 dépôts où wfx avait été injecté dans des fichiers de workflow de GhostAction. Si le nettoyage d'octobre n'a été que partiel, terminez-le maintenant.
6. Surveiller. Utilisez les résultats de la traque comme référence, et déclenchez désormais des alertes sur les nouveaux identifiants fédérés, les modifications de politiques de confiance et les modifications de fichiers de workflow.

Renforcer la protection des clés des fournisseurs d'IA dans la CI

Selon nous, les clés des fournisseurs d'IA méritent une place explicite dans tout plan de rotation, aux côtés des identifiants cloud. La Cloud Security Alliance recommande de placer les clés d'IA derrière des plafonds de dépenses par projet et des alertes sur les anomalies d'utilisation, de préférer dans la CI des identifiants de courte durée ou délivrés par un proxy plutôt que des clés statiques, et d'inclure les fournisseurs d'IA dans les procédures de rotation en cas d'incident, aux côtés des identifiants cloud et de registres.

En pratique, attribuez à chaque projet sa propre clé avec son propre plafond, afin qu'une seule fuite ne puisse pas épuiser un budget partagé. Lorsque c'est possible, faites passer les appels de la CI par un proxy interne qui détient la vraie clé, de sorte que le workflow ne la voie jamais ; notre guide expliquant comment un proxy d'identifiants tient les clés d'API à l'écart des agents d'IA détaille ce modèle. La même discipline s'applique en amont de la CI. Nous vous conseillons de vérifier aussi les postes des développeurs, car les fichiers de configuration locaux des agents peuvent contenir des identifiants actifs ; notre guide pour auditer les paramètres locaux des agents et renouveler les clés exposées couvre cette vérification.

Erreurs courantes dans la réponse à wfx

• Considérer la rotation comme la ligne d'arrivée. Corrigez d'abord la configuration de confiance (étape 1 du confinement).
• Se fier aux listes de blocage IP du 10 novembre. Elles ne détectent pas les copies de l'ère Telegram.
• Supposer que le blocage de GitHub vous a protégé. Vérifiez les hooks de package.json, pas seulement les fichiers de workflow.
• Ne vérifier que les dépôts dont vous êtes propriétaire. Délimitez le périmètre selon l'accès en écriture, y compris les droits de collaborateur et d'organisation.
• Prendre les chiffres publics pour un verdict. Les chiffres publics ne peuvent vous dire ni que vous avez été touché, ni que vous ne l'avez pas été ; vos propres journaux, si.
• Laisser le nettoyage de GhostAction inachevé. Revérifiez les comptes et les fichiers de workflow concernés en octobre.

Mises en garde et limites de ce que nous savons

Les chiffres publics proviennent de recherches GitHub effectuées à des moments précis, alors que la campagne était encore en cours : ce sont donc des instantanés pris en pleine campagne plutôt que des totaux définitifs. Ils mesurent aussi des choses différentes : les pull requests ouvertes, les commits reçus et les exécutions confirmées ne sont pas interchangeables, et le nombre de commits relevé par SafeDep ne signifie pas nécessairement que la charge utile s'est exécutée.

Nous vous conseillons de ne pas supposer que les jeux de données externes reflètent ce qui s'est passé dans vos dépôts privés ou vos instances d'entreprise. Pour la plupart des organisations, ce sont leurs propres journaux d'audit, leurs journaux Entra et CloudTrail qui constituent les preuves principales, la recherche publique servant de contexte.

Les indicateurs ont déjà changé une fois, comme le montre le passage d'adresses IP fixes à Telegram. Les messages de commit et les noms d'identifiants pourraient changer eux aussi : consultez donc les derniers IOC publiés par les fournisseurs avant de vous appuyer sur un schéma unique.

La Cloud Security Alliance, citant GitGuardian, rapporte que GhostAction a utilisé environ 1,900 comptes compromis pour cibler plus de 30,000 dépôts en octobre. Mis en regard du décompte d'Aikido de 61,764 dépôts pour wfx, cela donne deux vagues espacées d'environ un mois, la seconde étant à peu près deux fois plus importante en nombre de dépôts ciblés. Deux points de données ne suffisent pas pour parler de tendance, mais ils justifient amplement de se préparer à une nouvelle vague.

Ce guide ne remplace pas une mission formelle de réponse à incident lorsque des données réglementées ou un accès cloud de production sont en jeu.