FakeGit relance 17 610 faux dépôts GitHub qui installent SmartLoader pour voler les sessions
Le 8 octobre 2026, Apiiro révèle que la campagne FakeGit a réactivé 17 610 faux dépôts GitHub qui distribuent le chargeur SmartLoader, dont plusieurs centaines imitent des compétences IA et des serveurs MCP. Avant d’installer un dépôt depuis GitHub, vérifiez le propriétaire du compte et privilégiez les registres officiels.
8 octobre 2026. Apiiro, plateforme de sécurité de la chaîne d’approvisionnement logicielle, publie un décompte qui donne le vertige : 17 610 faux dépôts sur GitHub distribuent le chargeur SmartLoader. 4 octobre 2026. La campagne FakeGit a repris son activité, cette fois pour pousser l’infostealer StealC. 2 999 par heure. C’est le rythme de création observé au pic, sans qu’un seul nouveau dépôt n’ait été créé. Pourquoi c’est important : la flotte malveillante était déjà en place et n’a fait qu’être réorientée, ce qui rend les suppressions au compte-gouttes impuissantes — et les développeurs qui installent des « compétences IA » depuis GitHub sont la cible désignée.
Une flotte déjà là, simplement réorientée
La découverte la plus dérangeante d’Apiiro tient en une phrase rapportée dans le rapport : « Personne n’a eu à créer un seul dépôt. La flotte était déjà là. Elle a juste été réorientée. » Le groupe derrière FakeGit ne repart pas de zéro à chaque campagne : il réactive un stock de dépôts déjà indexés, déjà référencés, et se contente d’en changer la charge utile.
Les chiffres racontent la mécanique. En 34 heures, FakeGit a poussé plus de 13 000 dépôts, avec un pic de 2 999 dépôts à l’heure. Dans les commits échantillonnés, 97 % ne touchaient que le fichier README, et 88 % pointaient leur bouton « Download » vers une archive ZIP qui installe SmartLoader. Le pattern est industriel : un README alléchant, un bouton de téléchargement, un ZIP piégé.
SmartLoader n’est que le premier étage. C’est un chargeur — son rôle est de déposer la charge finale, ici l’infostealer StealC, qui aspire identifiants, cookies et jetons de session. Les faux dépôts utilisent en majorité des comptes jetables, mais les chercheurs ont identifié au moins 700 comptes qui semblent appartenir à de vrais développeurs — des comptes compromis, détournés pour donner au leurre une réputation légitime.
Le maillon faible : les compétences IA et les serveurs MCP
Ce qui fait passer FakeGit du rang de nuisance à celui de menace sérieuse, c’est sa cible. Dès juillet, la plateforme Island avait documenté 7 600 faux dépôts poussant SmartLoader, et noté que 800 d’entre eux se faisaient passer pour des compétences IA ou des serveurs MCP apparaissant dans les registres et catalogues publics d’IA.
Le MCP, le Model Context Protocol, est devenu le standard de fait pour brancher des agents IA sur des outils externes. Des milliers de développeurs installent des « serveurs MCP » trouvés sur GitHub pour donner à leur assistant des capacités nouvelles — lire des fichiers, interroger des bases, piloter des services. C’est exactement le genre de greffon qu’on installe vite, en se fiant au nom et au README, sans auditer le dépôt.
Un serveur MCP malveillant ne se contente pas de voler des cookies : il s’exécute dans l’environnement même où l’agent IA tourne, avec les accès de ce dernier. Pour un développeur, installer un faux serveur MCP, c’est donner la main à un attaquant sur son poste et, souvent, sur les jetons de ses outils de développement — GitHub, registres de paquets, services cloud.
Pourquoi la suppression ne suffit pas
La raison pour laquelle FakeGit survit aux vagues de suppression est structurelle, et Apiiro la détaille en trois constats.
D’abord, les listes de blocage ne couvrent qu’une fraction de la flotte. « 71 % de la flotte était absente de URLhaus avant notre rapport », note la société. Les suppressions reposent sur des listes de dépôts connus, or l’essentiel du stock n’y figure jamais.
Ensuite, une liste DNS ne peut pas bloquer un fichier sur GitHub sans bloquer GitHub. Si le leurre pointe vers une archive hébergée sur le domaine github.com lui-même, une règle de blocage par domaine est inopérante — il faudrait couper l’accès à toute la plateforme.
Enfin, les copies de secours pullulent. Les chercheurs ont retrouvé des archives malveillantes dans des forks, des fichiers plus anciens, des assets de release, des pièces jointes d’issue et des dépôts d’hébergement séparés. Résultat : « Supprimez un fichier et l’opérateur pointe le leurre vers une copie de rechange — un fork, un ancien ZIP, un asset de release ou une pièce jointe d’issue. » La suppression ciblée devient un jeu du chat et de la souris que le défenseur perd à chaque tour.
Réagir comme si le compte était compromis
Les recommandations d’Apiiro sont directes, et la plus importante porte sur la réaction, pas sur la prévention. Si l’exécution de SmartLoader est suspectée, il faut traiter l’incident comme une compromission de compte GitHub : révoquer les sessions actives et les jetons d’accès, et passer aux passkeys.
C’est la bonne grille de lecture. SmartLoader étant un chargeur, sa présence signifie que StealC — ou un autre étage final — a très probablement tourné sur la machine. Un infostealer vise en premier lieu les jetons de session et les identifiants enregistrés : révoquer les sessions coupe la valeur de ce qui a déjà été volé, et les passkeys rendent la réutilisation des mots de passe capturés plus difficile.
En prévention, la consigne est simple et ancienne : vérifier le propriétaire du dépôt. Un compte récent, sans historique, qui héberge un « serveur MCP » au nom alléchant est un signal d’alarme. Pour les compétences IA et les serveurs MCP, la source d’installation doit être les registres officiels ou les dépôts des éditeurs, pas un lien trouvé au hasard d’une recherche.
Repérer un faux dépôt avant de cliquer
La défense individuelle passe d’abord par un regard critique sur le dépôt, avant même d’ouvrir l’archive. Trois signaux se recoupent, et chacun se vérifie en trente secondes.
- Le propriétaire. Un compte créé récemment, sans dépôt notable et sans historique de contributions, qui héberge un « serveur MCP » portant exactement le nom de l’outil recherché est un drapeau rouge. Regarder la date de création du compte et son ancienneté suffit souvent à trancher.
- Le contenu. Un dépôt dont les commits ne touchent qu’un README — pas de code, pas de tests, pas de CI — n’est pas un projet, c’est une vitrine. Les 97 % de commits limités au README relevés par Apiiro sont la signature même du leurre.
- Le bouton de téléchargement. Un dépôt légitime publie son code dans le dépôt ou sur le registre de son langage, pas dans une archive ZIP pointée par un bouton « Download » du README.
La règle qui résume tout tient en une phrase : pour une compétence IA ou un serveur MCP, la source d’installation est le registre officiel ou le dépôt de l’éditeur, jamais un lien intermédiaire trouvé au fil d’une recherche.
Verdict
Si vous installez des compétences IA ou des serveurs MCP depuis GitHub, changez de réflexe aujourd’hui : vérifiez le propriétaire du dépôt, son historique et son ancienneté, et préférez systématiquement le registre ou le dépôt officiel de l’éditeur — un faux serveur MCP s’exécute avec vos accès et vos jetons, pas dans un bac à sable. Si un membre de votre équipe a pu exécuter un faux dépôt, ne cherchez pas à « nettoyer » : traitez l’événement comme une compromission de compte, révoquez sessions et jetons, et basculez vers des passkeys. Pour la défense collective, ne comptez pas sur les suppressions de GitHub — une flotte de 17 610 dépôts réorientables ne se résorbe pas par des listes de blocage partielles, elle se contourne par la vigilance des personnes qui cliquent.