Des milliers de comptes GitHub viennent d’être piratés et l’ampleur donne des sueurs froides aux développeurs. L’enquête des chercheurs d’Aikido Security recense 4 837 comptes compromis et 61 764 dépôts visés par des demandes de modification suspectes.
Depuis le 10 novembre 2026, la campagne wfx-loot détourne des comptes GitHub pour faire exécuter du code malveillant dans des projets logiciels. Le prétexte était une banale maintenance. Le plus inquiétant ? Les pirates ont utilisé les outils de développement eux-mêmes pour commettre leurs méfaits, avant de tenter d’effacer les preuves de leur passage.
Comment GitHub a-t-il été piraté ?
Les chiffres publiés par les chercheurs d’Aikido Security donnent le tournis. Au moins 1 806 dépôts ont exécuté le programme voleur de secrets, selon un premier décompte. Une autre partie du bilan avance le chiffre de 1 835.
Sachez tout de même qu’un dépôt ciblé n’est pas nécessairement un dépôt pillé. Et les chercheurs ne publient pas de nombre exhaustif de secrets effectivement récupérés. Une alerte sérieuse pour les équipes de développement.
En octobre, une autre campagne, GhostAction, avait déjà compromis près de 1 900 comptes. Des recoupements existent entre les victimes et certains fichiers utilisés, mais rien ne permet d’attribuer les deux opérations au même groupe.
Mais comment les malfaiteurs ont-ils piraté GitHub ? La méthode commence presque poliment. À l’aide d’identifiants dérobés, les attaquants ouvrent une pull request intitulée « docs: dependency audit notes », depuis une branche nommée wfx-docs. Derrière ce prétendu audit se cache un test d’accès en écriture.
Quand l’accès le permet, les pirates ajoutent un script malveillant à un workflow GitHub Actions, à une étape d’installation npm ou à une branche temporaire. Ces automatismes servent normalement à tester et préparer les logiciels. Cette fois, ils exécutent du code hostile avec les autorisations disponibles. Le contrôle qualité se transforme en cambriolage. Bien joué, malheureusement.
Il ne s’agit pas d’une faille avérée dans les serveurs de GitHub. L’attaque exploite surtout des comptes déjà compromis et des permissions trop généreuses. Un compte de confiance devient une porte d’entrée.
Des clés cloud aux accès IA, le butin dépasse largement GitHub
Que cherchent les pirates ? Pas seulement du code source. Leur programme cible les secrets de GitHub Actions, les jetons d’accès, les clés SSH et les identifiants permettant de travailler avec AWS, Azure ou Google Cloud. Il recherche aussi des accès à différents services d’IA et outils de programmation.
C’est là que l’affaire prend une autre dimension. Une clé récupérée dans un dépôt peut ouvrir l’accès à des ressources extérieures, selon ses permissions. Un pirate pourrait alors consulter des données, modifier des services ou se maintenir dans une infrastructure. Ces dégâts potentiels ne sont pas démontrés chez chaque victime.
Selon Aikido, les attaquants ont également tenté de créer des accès persistants dans certains environnements cloud, notamment à travers des clés AWS et des identifiants fédérés Azure. Ce risque rappelle pourquoi changer un mot de passe ne suffit pas toujours après un vol d’accès.
Le programme ne se contente pas de fouiller les secrets. Les chercheurs décrivent aussi un mécanisme destiné à annuler les modifications, supprimer les exécutions suspectes et effacer leurs journaux. Le nettoyage pouvait être rapide.
Résultat, un projet qui paraît propre aujourd’hui ne l’était pas forcément hier. Les équipes de sécurité doivent passer en revue l’historique des modifications et les événements du dépôt. Elles doivent aussi repérer d’éventuelles interruptions dans la numérotation des exécutions GitHub Actions.
Cette méthode rappelle d’autres attaques contre la chaîne d’approvisionnement logicielle, qui exploitent un mécanisme de confiance pour compromettre un plus grand nombre de systèmes. Sauf qu’ici, les pirates essaient également de faire disparaître le mode d’emploi de leur intrusion.
Votre projet GitHub a-t-il été piraté ? Voici ce qu’il faut vérifier
Si vous gérez des dépôts GitHub, commencez par rechercher les demandes de modification intitulées « docs: dependency audit notes », les branches wfx-docs et les commits suspects depuis le 10 novembre. L’analyse de SafeDep détaille les autres indicateurs à surveiller.
Si un compte a été compromis, révoquez ses sessions et jetons, examinez ses autorisations et activez une authentification multifacteur robuste. Si le malware a pu s’exécuter, considérez les secrets accessibles au workflow comme exposés : renouvelez-les et vérifiez aussi les accès persistants dans les plateformes cloud. Changer les clés ne supprime pas forcément un accès malveillant.
Enfin, réduisez les permissions des workflows et imposez des contrôles sur leurs modifications sensibles. GitHub reste un outil incontournable ; cette campagne ne prouve pas que la plateforme entière a été piratée.
Cette attaque rappelle une réalité moins rassurante. Un compte développeur légitime peut servir de couverture idéale à un pirate. Et si des clés de production sont exposées, les risques dépassent largement le simple code informatique.
- Partager l'article :
