Une campagne vole les secrets CI de 1 800 dépôts via 4 837 comptes GitHub compromis

10 novembre 2026, 12 h 45 UTC. Un acteur commence à utiliser des identifiants GitHub volés pour pousser du code dans des dépôts. 11 novembre 2026, 15 h 00 UTC. La rafale de pull requests de sondage s’arrête, après avoir touché 61 764 dépôts. 12 novembre 2026. Aikido Security publie son analyse et baptise la campagne wfx-loot. Pourquoi c’est important : l’attaquant ne visait pas votre code, il visait les secrets que vos workflows CI peuvent lire — et il a exfiltré ceux d’au moins 1 835 dépôts.

Ce que fait réellement wfx-loot

wfx-loot est le nom que les chercheurs d’Aikido Security donnent à la campagne, d’après le terme que l’attaquant utilise lui-même pour désigner son outil et le butin qu’il collecte. Le scénario est un credential stuffing à l’échelle de la plateforme : l’acteur détient des identifiants — probablement issus de fuites antérieures ou de stealers installés sur les postes de développeurs — pour 4 837 comptes GitHub dont l’authentification n’est pas protégée par un second facteur.

Pour chaque dépôt que ces comptes peuvent modifier, la séquence est mécanique. D’abord une sonde : une pull request intitulée « docs: dependency audit notes » ouverte depuis une branche wfx-docs. Ensuite, si le compte a les droits, des commits nommés « ci: refresh build cache », « chore: add ci helper » ou « chore: add dependency audit workflow » déposent la charge réelle — un workflow GitHub Actions conçu pour exfiltrer les secrets de CI et les identifiants cloud que le runner peut atteindre. Les branches portent des noms jetables du type chore/ suivi de huit caractères aléatoires.

La recherche GitHub renvoie 61 839 pull requests « docs: dependency audit notes » ouvertes entre le 10 novembre à 12 h 45 UTC et le 11 novembre à 15 h 00 UTC. 10 431 d’entre elles ont atteint des dépôts que le compte ne possède pas, via des accès de collaborateur ou d’organisation. Et 92 % sont encore ouvertes — ce qui veut dire que la plupart des propriétaires n’ont pas remarqué la sonde.

Le pipeline devient la surface d’attaque

Le point qui change tout, c’est que la cible n’est pas le dépôt lui-même. C’est le pipeline. Un workflow GitHub Actions s’exécute avec les permissions du dépôt et peut lire les secrets et les rôles cloud configurés pour lui. En injectant un workflow malveillant dans un dépôt où un compte compromis peut écrire, l’attaquant fait exécuter son code dans le contexte de confiance du dépôt — un contexte qui lui ouvre, selon les cas, des clés d’API de production, des identifiants de registres, ou des rôles AWS, GCP ou Azure assumables par le runner.

Aikido estime qu’au moins 1 835 dépôts ont réellement exécuté la charge, avec des identifiants exfiltrés. Les journaux d’exécution ont été supprimés dans les dépôts touchés — un signe que l’attaquant a collecté le butin et effacé ses traces. L’équipe précise que ce chiffre est probablement sous-estimé : on ne peut pas comptabiliser ce qui a été nettoyé.

La campagne a aussi débordé sur les écosystèmes de paquets, via les déclencheurs de publication automatique des comptes compromis. Au moins 50 utilisateurs compromis publient des paquets sur npm, Go, Packagist, PyPI ou crates. Deux paquets malveillants sont identifiés à ce jour : digitalelvis/neuronai-studio version 3.14.3 sur Packagist, et le module Go github.com/onuragtas/docker-env versions 1.0.278 et 1.0.280 — ce dernier ne porte la charge que dans un fichier de workflow, ce qui limite son impact aux builds qui l’exécuteraient.

C’est un rappel brutal d’une règle déjà documentée sur ce blog : GitHub a dû bloquer pull_request_target précisément parce que les workflows sont devenus une surface d’exécution de code, et la fuite de variables d’environnement de Railway montrait déjà ce que coûte un secret qui traîne dans un pipeline.

D’où viennent 4 837 comptes

Aikido ne détaille pas la provenance des identifiants, mais le profil est reconnaissable : des comptes sans authentification à deux facteurs, dont les mots de passe — ou les tokens d’accès personnel — ont fui via des infostealers, ces malwares qui siphonnent sessions et mots de passe depuis les navigateurs des développeurs. C’est le chaînon manquant du credential stuffing : sans 2FA, un identifiant volé vaut un accès en écriture. La campagne ne repose sur aucune faille de GitHub, mais sur la réutilisation d’identifiants déjà compromis — ce qui la rend difficile à attribuer et facile à répéter.

Comment savoir si vous êtes touché

Le signal d’alarme est simple à chercher. Si l’un de ces éléments est apparu dans un dépôt où vous avez des droits d’écriture à partir du 10 novembre, vous êtes dans le périmètre :

• une branche wfx-docs ou une pull request « docs: dependency audit notes » ;
• des commits « ci: refresh build cache », « chore: add ci helper » ou « chore: add dependency audit workflow » ;
• une branche courte nommée chore/ suivie de huit caractères aléatoires.

La règle d’Aikido est sans ambiguïté : si la charge a tourné dans votre dépôt, considérez chaque secret et chaque rôle cloud accessible à vos workflows comme compromis. Cela signifie révoquer et faire tourner tous les secrets — pas seulement ceux que vous pensez avoir été lus —, révoquer les sessions et les clés des rôles cloud assumables, et auditer l’historique des workflows à la recherche du fichier injecté.

Au-delà du triage, deux réflexes limitent les dégâts : geler les comptes compromis — révoquer leurs tokens et leurs sessions — et activer le 2FA partout, en priorité sur les comptes qui ont des droits d’écriture sur des dépôts de production. La protection de branche avec approbation obligatoire, elle, ne bloque pas la sonde — mais elle empêche la charge d’atteindre la branche par défaut sans qu’un humain l’ait vue.

# lister les workflows modifiés récemment dans un clone local
git log --since=2026-11-10 --name-only -- .github/workflows/ | grep -v '^$'

Le correctif durable n’est pas technique mais organisationnel : exiger une revue sur tout changement de workflow, activer la protection de branche avec approbation obligatoire, et imposer le 2FA sur tous les comptes ayant accès à des dépôts de production. Un workflow est du code exécutable — il doit être traité avec la même rigueur qu’une modification du cœur applicatif.

Verdict

Si un dépôt auquel vous avez accès a reçu une pull request « docs: dependency audit notes » ou une branche chore/ après le 10 novembre 2026, traitez tous ses secrets CI et rôles cloud comme compromis et faites-les tourner immédiatement, même si le workflow ne semble pas avoir tourné — la sonde seule suffit à confirmer que le compte était compromis. Le vrai risque n’est pas ce qui a déjà été volé, c’est ce qui reste exploitable : des identifiants de production encore valides dans des dépôts dont 92 % des sondes sont encore ouvertes. Si aucun de vos dépôts n’a reçu ces artefacts, le risque immédiat est faible, mais la campagne est un cas d’école pour imposer dès maintenant le 2FA et la revue obligatoire des workflows — c’est le seul moyen de rendre ce vecteur inopérant.

Références

• Aikido Security — « wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories » (Oliver Smith, 12 novembre 2026)
• The Hacker News — « Attacker Used 4,837 Hijacked GitHub Accounts to Run a CI Secret Stealer in 1,806+ Repositories » (12 novembre 2026)
• ETTAYEB — GitHub bloque pull_request_target
• ETTAYEB — la fuite de variables d’environnement chez Railway