GitHub : 4 837 comptes volés pillent les secrets de CI

Ce qui se passe

Depuis le mardi 10 novembre, un attaquant se sert des identifiants volés de 4 837 comptes GitHub pour installer un voleur de secrets dans les dépôts où ces comptes ont l'accès en écriture. Aikido Security l'a vu s'exécuter dans au moins 1 806 dépôts. SafeDep compte de son côté 8 093 dépôts ayant reçu des commits malveillants entre le 10 novembre, 12 h 46 UTC, et le 12 novembre, 4 h 36 UTC — en ne regardant que les branches par défaut des dépôts publics, donc en dessous de la réalité. L'origine des identifiants n'est pas connue.

Le déroulé

1. Le test d'accès : une pull request docs: dependency audit notes, ouverte depuis une branche wfx-docs. Elle a visé 61 764 dépôts, dont 10 431 par un accès de collaborateur ou d'organisation ; 92 % de celles-là étaient encore ouvertes au moment du relevé.
2. Le voleur : ajouté à un workflow existant (7 309 dépôts) ou glissé dans un hook postinstall de package.json (771 dépôts), qui tourne aussi sur le poste de quiconque fait npm install.
3. L'effacement : commit annulé en général en quelques minutes, journaux du run supprimés, souvent avec le run.
4. L'envoi : HTTP POST vers trois serveurs, ou un canal Telegram — environ un cinquième des 200 commits examinés par SafeDep n'utilisaient que Telegram.

Il ramasse les secrets et variables d'Actions, le GITHUB_TOKEN, les jetons OIDC et d'exécution Actions, les clés de services d'IA, les secrets en mémoire des processus du runner, et les fichiers d'identifiants AWS, Azure, GCP, Kubernetes, npm, PyPI et SSH. Il copie aussi le dépôt, ses 100 derniers commits et les artefacts récents. Sur un runner auto-hébergé, il prend en plus les identifiants de métadonnées d'instance, l'état Docker et les unités systemd.

Pourquoi changer les secrets ne suffit pas

Le voleur échange les jetons OIDC de GitHub contre des sessions AWS, GCP et Azure, puis pose des accès durables :

• sur AWS, des clés d'accès IAM longue durée, et une politique de confiance de rôle réécrite pour accepter n'importe quel compte AWS ;
• sur Azure AD, des identifiants fédérés préfixés wfx-ci- : les workflows du dépôt se connectent alors sans secret stocké, même après la rotation de tous les jetons.

Les paquets touchés

• Packagist : digitalelvis/neuronai-studio 3.14.3, publiée le 11 novembre. composer install seul ne lance pas le voleur ; un npm install dans le dossier du paquet sous vendor/, si. Bloquez 3.14.3 et épinglez 3.14.2 ou antérieure ; toute machine qui l'a installée ou ouverte est à traiter comme compromise.
• Go : github.com/onuragtas/docker-env v1.0.278 et v1.0.280, où le voleur n'est que dans un workflow (code Go et binaires inchangés, retrait conseillé quand même) ; github.com/vkuznet/gocurl en v0.0.0-20261111095532-8d5aad0cb0da, à bloquer.
• WebdriverIO : 28 dépôts touchés par des commits signés du robot wdio-bot, sans release affectée ; son jeton est à considérer comme volé.

Au moins 50 des comptes compromis publient sur npm, Go, Packagist, PyPI ou crates. Ils recoupent ceux de la vague GhostAction d'octobre, sans attribution au même acteur à ce stade.

Comment vérifier

Depuis le 10 novembre, dans tout dépôt où vous pouvez écrire :

• branches wfx-docs, chore/[a-z0-9]{8} (éphémère), ci-check-[0-9]{4} ;
• pull request docs: dependency audit notes ;
• commits ci: refresh build cache (environ 1 500 lignes ajoutées à un workflow), chore: add ci helper (script .ci-xxxxxx.sh et hook postinstall), chore: add dependency audit workflow (.github/workflows/build-audit-xxxxxx.yml), chore: initial commit, ci: restore, ci: cleanup ;
• SHA-256 du script : 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf ;
• destinations : 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil, 153.75.82[.]159:8080.

L'absence d'artefacts wfx-loot, d'entrées de cache wfx- ou de résumés WFX-BEGIN ne prouve rien : le signe le plus fiable est un commit de l'attaquant sans numéro de run.

Côté cloud : identifiants fédérés wfx-ci-* inconnus dans Entra ID ; dans CloudTrail, des sessions AssumeRoleWithWebIdentity ou AssumeRole nommées wfx-* suivies de CreateAccessKey ou UpdateAssumeRolePolicy ; sur GCP, des appels GenerateAccessToken et SignJwt depuis votre pool d'identité GitHub ; dans Vault, des connexions JWT venant de l'émetteur OIDC de GitHub.

Si un dépôt est touché

Tout compte qui a ouvert une pull request de test est compromis, même si le voleur n'a jamais tourné. Révoquez ses jetons, autorisations OAuth, clés SSH et sessions, activez la 2FA, puis changez chaque secret et variable que le dépôt peut lire, et supprimez les accès cloud listés plus haut.

Source : The Hacker News, en anglais, d'après l'analyse d'Aikido Security et celle de SafeDep.