RéponsesPublié25 sources
wfx-loot : des comptes GitHub piratés ont exposé les secrets CI de milliers de dépôts
wfx loot s’est appuyée sur des identifiants GitHub volés, et non sur une faille de GitHub Actions, pour tester l’accès à 61 764 dépôts. Aikido fait état d’au moins 1 835 dépôts où le code malveillant s’est exécuté et où des identifiants ont été exfiltrés ; certains comptes rendus antérieurs citent 1 806.
Publié parModifié avec GPT-6 LunaImages générées avec GPT Image 2
Réponse de recherche
Points clés à retenir
- wfx loot s’est appuyée sur des identifiants GitHub volés, et non sur une faille de GitHub Actions, pour tester l’accès à 61 764 dépôts.
- Aikido fait état d’au moins 1 835 dépôts où le code malveillant s’est exécuté et où des identifiants ont été exfiltrés ; certains comptes rendus antérieurs citent 1 806.
- Les équipes concernées devraient examiner les demandes de fusion suspectes, révoquer les jetons compromis et renouveler les secrets accessibles aux workflows touchés.
Prompt IA
openai.comCreate a landscape editorial hero image for this Studio Global article: What was the wfx-loot GitHub credential-theft campaign reported by Aikido Security, when did it begin and how long was it active, how did at. Article summary: wfx-loot was a mass CI credential-theft campaign that used valid stolen GitHub credentials—not a GitHub Actions vulnerability—to place secret-stealing code in repositories the compromised accounts could write to. Aikido . Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
wfx-loot est une campagne de vol d’identifiants qui s’est servie de comptes GitHub compromis pour sonder des dépôts et, lorsque ces comptes disposaient d’un accès en écriture, y introduire du code destiné à dérober des secrets dans les environnements d’intégration continue (CI). Aikido a recensé 4 837 comptes compromis et des demandes de fusion dans 61 764 dépôts. Selon son bilan publié, la charge malveillante s’est exécutée et des identifiants ont été exfiltrés depuis au moins 1 835 dépôts.4
9
Quand la campagne a-t-elle eu lieu ?
L’activité aurait commencé vers 12 h 45 UTC le 10 novembre 2026. Un compte rendu situe la période des demandes de fusion de test jusqu’au 11 novembre à 15 h UTC, soit environ 26 heures et 15 minutes.6
7 Cette fenêtre correspond aux sondages observés : elle ne confirme pas que toute activité liée à la charge malveillante, ni toute utilisation ultérieure des identifiants volés, ait pris fin à ce moment-là.
Les chiffres décrivent différentes étapes de l’opération :
- 4 837 comptes ont été signalés comme compromis.
- 61 764 dépôts ont reçu des demandes de fusion de test. Ce total désigne les dépôts sondés, pas ceux où l’exécution du logiciel malveillant est avérée.
- Au moins 1 835 dépôts figurent dans le bilan publié par Aikido pour l’exécution de la charge et l’exfiltration d’identifiants.
9
Certains comptes rendus publiés à la même période avancent un chiffre inférieur, 1 806.6
10 Les informations disponibles n’expliquent pas cet écart : il faut donc considérer ces nombres comme des bilans distincts, et non les additionner. Les sources fournies ne permettent pas non plus d’étayer l’affirmation ultérieure d’environ 1 970 cas publics confirmés parmi plus de 66 000 cibles.
Comment les attaquants ont testé les accès
Les attaquants ont ouvert des demandes de fusion intitulées docs: dependency audit notes, à partir de branches nommées wfx-docs. Ces demandes servaient de sondes : elles permettaient de vérifier si un compte compromis pouvait modifier le dépôt visé.3
4
9
Lorsque les autorisations le permettaient, les attaquants introduisaient une charge destinée à voler des secrets dans l’environnement CI. La campagne reposait sur des identifiants valides dérobés, et non sur une vulnérabilité de GitHub Actions.4
9 OX Security décrit le logiciel malveillant comme un script shell unique d’environ 1 500 lignes.
31
Des changements malveillants et des journaux d’exécution auraient été supprimés dans certains cas, compliquant les investigations.1
6 Les éléments disponibles étayent le schéma général — sondage, exécution de la charge, puis nettoyage — mais ne démontrent pas que chaque mode de déploiement ou chaque message de commit cité ait été utilisé dans toutes les infections.
Quels secrets étaient visés ?
L’objectif documenté était de récupérer les identifiants accessibles aux tâches CI, notamment les secrets GitHub Actions et des identifiants cloud. Les comptes rendus évoquent aussi des tentatives de récupération de jetons de services d’IA.3
9 L’analyse d’OX Security cite notamment des identifiants AWS, Azure et Google Cloud parmi les cibles.
31 D’autres articles indiquent que le logiciel pouvait rechercher des secrets dans la mémoire des processus du runner, mais les extraits disponibles ne permettent pas d’établir à quelle fréquence cette méthode a réussi.
17
29
Un résumé indique que le logiciel aurait tenté d’étendre son accès en modifiant des politiques de confiance AWS et en ajoutant des identifiants fédérés Azure.5 Il s’agit de comportements rapportés, pas d’une preuve que chaque dépôt touché — ou chaque compte cloud — ait été modifié. Les éléments disponibles portent sur le vol d’identifiants ; ils ne démontrent pas le vol de code source ou de bases de données clients.
9
15
Ce que les indicateurs permettent de conclure
Un compte rendu indique que 92 % des 10 431 demandes de fusion de test envoyées via des accès de collaborateur ou d’organisation étaient encore ouvertes lors de la vérification.10
19 Cela laisse penser que beaucoup de sondes n’avaient pas encore été traitées à ce moment-là, mais ne prouve pas qu’aucun propriétaire de dépôt ou aucune équipe de sécurité ne les avait repérées. Ce pourcentage ne concerne pas nécessairement toutes les demandes de fusion de la campagne.
Un guide d’investigation signale également 173 demandes de fusion de test provenant de 19 comptes et utilisant des jetons via l’application GitHub de Fly.io. Cette observation ne démontre pas, à elle seule, que l’infrastructure de Fly.io ait été compromise, ni que la charge malveillante se soit exécutée dans chacun des dépôts atteints par ces jetons.37
Vérifications recommandées aux équipes
En cas d’exposition possible, distinguez clairement les étapes dépôt sondé, charge malveillante introduite, charge exécutée et identifiants exfiltrés. Ces constats ne sont pas équivalents.
- Recherchez les indicateurs de sondage. Vérifiez les demandes de fusion intitulées
docs: dependency audit noteset les brancheswfx-docsdans les dépôts auxquels vos comptes pouvaient écrire. - Examinez les journaux CI et d’audit. Passez en revue les exécutions de workflow, les commits, l’activité des branches et les journaux cloud disponibles. Des numéros d’exécution manquants peuvent constituer une piste, car des suppressions de journaux et d’exécutions ont été rapportées ; une lacune ne prouve toutefois pas, à elle seule, une compromission.
1
24
- Révoquez les accès concernés. Révoquez les jetons GitHub que vous soupçonnez d’avoir été compromis et vérifiez les accès des comptes, collaborateurs et applications GitHub.
- Renouvelez largement les secrets exposés. Si la charge s’est exécutée, considérez comme potentiellement compromis les secrets et rôles cloud accessibles au workflow — pas seulement les identifiants encore visibles dans les journaux conservés.
3
- Recherchez une persistance dans le cloud. Vérifiez les modifications inattendues des politiques de confiance AWS et des applications ou identifiants fédérés Azure, ainsi que toute clé ou modification d’accès non autorisée.
5
- Conservez les éléments de preuve. Sauvegardez les journaux d’audit et les traces encore disponibles avant toute opération de nettoyage, puis consignez précisément les étapes de l’attaque que les éléments permettent d’établir.
Studio Global AI
Continuez vos recherches
Cette page comprend une réponse basée sur la source que vous pouvez continuer dans Studio Global.
Les gens demandent aussi
Quelle est la réponse courte à « wfx-loot : des comptes GitHub piratés ont exposé les secrets CI de milliers de dépôts » ?
wfx loot s’est appuyée sur des identifiants GitHub volés, et non sur une faille de GitHub Actions, pour tester l’accès à 61 764 dépôts.
Quels sont les points clés à valider en premier ?
wfx loot s’est appuyée sur des identifiants GitHub volés, et non sur une faille de GitHub Actions, pour tester l’accès à 61 764 dépôts. Aikido fait état d’au moins 1 835 dépôts où le code malveillant s’est exécuté et où des identifiants ont été exfiltrés ; certains comptes rendus antérieurs citent 1 806.
Que dois-je faire ensuite en pratique ?
Les équipes concernées devraient examiner les demandes de fusion suspectes, révoquer les jetons compromis et renouveler les secrets accessibles aux workflows touchés.
Sources
bleepingcomputer.comHackers compromise 4,800 GitHub accounts to steal cloud credentials
al-ice.aiProbe, Payload, Vanish: 4,837 Hijacked GitHub Accounts Fed a CI Secret Stealer Across 61,764 Repositories
unbiasedheadlines.comStolen Logins for 4,837 GitHub Accounts Used to Run Secret Stealer in at Least 1,806 Repositories, Researchers Say