FakeGit autonome Agents IA transformer GitHub en vecteur de malware

Les chercheurs en cybersécurité ont identifié une vaste campagne qui profite de GitHub comme une plateforme de distribution : près de 7 600 dépôts malveillants créés par environ 6 600 profils, dont plus de 800 sont transmis aux « compétences » de l'IA ou aux serveurs du « Model Context Protocol (MCP) » pour fournir un chargeur initial connu sous le nom de SmartLoader qui, à son tour, instate des voleurs d'information comme VolC. La chose troublante n'est pas seulement la quantité, mais la mécanique : des projets contrefaits ou clonés, des profils qui imitent les développeurs légitimes et convainquant README qui induisent des téléchargements de fichiers ZIP obstrués qui activent une chaîne de charge basée sur LuaJIT pour exécuter le code osfusqué.

La campagne, appelée FakeGit par les chercheurs, a exploité la demande réelle d'intégrations et d'outils de l'IA - des connecteurs Gmail et WhatsApp aux profits pour Jenkins, Docker et Databricks - et a réalisé plus de 14 millions de téléchargements à travers les actifs de GitHub Release dans quelques dépôts de campagne. L'attrait fonctionnel et la connaissance des noms réels et des flux de travail étaient suffisants pour légitimer le téléchargement du ZIP malveillant.

Plus alarmante est l'évolution appelée AgentBaiting : les agents autonomes de l'IA (les "assistants" qui cherchent et installent des compétences ou des serveurs MCP) peuvent découvrir ces dépôts pour eux-mêmes, lire README comme s'il s'agissait d'une documentation authentique et exécuter des instructions malveillantes sans intervention humaine. La preuve indique que des modèles tels que Anthropic Claude Code, Google Gemini et OpenAI ChatGPT peuvent être induits en erreur pour exposer ou recommander ces dépôts, qui transforme une technique d'ingénierie sociale orientée vers l'homme en un vecteur qui fonctionne à l'échelle et sans supervision.

Ce changement de paradigme a de graves répercussions sur la sécurité des logiciels et la confiance dans les documents publics. Lorsque la recherche et l'installation sont effectuées par un agent, toutes les défenses traditionnelles qui dépendent de l'examen humain cessent de fonctionner. De plus, la présence de ces dispositifs sur les marchés et les listes publiques (LobeHub, Glama, MCP.so, MCP Market, etc.) ajoute une couche de légitimité apparente qui rend la détection difficile et de plus en plus accessible.

Les défenses doivent agir sur plusieurs fronts. Au niveau opérationnel, les organisations devraient créer et tenir à jour un catalogue vérifié des compétences, des serveurs MCP et des suppléments approuvés, tester toute nouvelle capacité d'agent dans des environnements isolés et appliquer le principe du privilège minimum aux comptes et aux agents qui peuvent télécharger ou exécuter du code. Il est essentiel d'exiger des signatures de code et des artefacts reproductibles, de mettre en œuvre des politiques qui bloquent les décharges automatiques et les exécutions par des agents et de vérifier en temps réel les itinéraires d'exécution et d'exfiltration avec EDR et le contrôle d'évacuation.

Les concepteurs et les dépositaires publics ont également la responsabilité : l'adoption de pratiques d'intégrité de la chaîne d'approvisionnement (p. ex., la signature des communiqués, la fourniture de SBOM et des cadres suivants comme SLSA) réduit la probabilité que les appareils malveillants circulent comme s'ils étaient légitimes. Les plates-formes qui hébergent les dossiers de compétences et le MCP devraient introduire des processus minimaux de vérification de l'identité et de la réputation, de balayage automatisé des appareils et de canaux clairs pour signaler et supprimer les listes suspectes.

Les fournisseurs de modèles devraient limiter la capacité des agents à exécuter des actions sans restriction, à mettre en œuvre des validations de source avant de renvoyer des liens ou des instructions impliquant l'exécution de code et à exposer les contrôles administratifs qui limitent les recherches et les opérations automatisées d'installation. La gouvernance des « voies agéniques » - les voies qu'un agent vient télécharger et exécuter un artefact - doit devenir une priorité opérationnelle.

Pour le matériel technique et responsable des risques, les mesures immédiates recommandées sont claires : établir des listes d'autorisation et des processus d'examen, sandbox de nouvelles intégrations, exiger des signatures et des métadonnées de la source, appliquer les paramètres et la détection du réseau pour les modèles SmartLoader/StealC, et éduquer les utilisateurs et les administrateurs sur le risque de résultats d'agents de confiance aveugle. La collaboration entre le secteur public et le secteur privé et les échanges du CIO sont également nécessaires pour accélérer l'identification et le blocage de campagnes similaires.

FakeGit n'a pas forcé une pause technique complexe : il a profité de la confiance, de l'automatisation et du volume. La leçon est double et urgente: d'une part, la sécurité de la chaîne d'approvisionnement doit mûrir (assurer l'intégrité et la traçabilité); d'autre part, les systèmes IA et les marques qui facilitent l'automatisation doivent concevoir des contrôles afin que l'autonomie ne devienne pas un moyen de diffuser les logiciels malveillants sur une échelle. De plus amples renseignements sur les pratiques et les guides visant à protéger la chaîne d'approvisionnement des logiciels figurent dans la documentation de GitHub sur la sécurité de la chaîne d'approvisionnement ( https: / / docs.github.com / fr / code-security / supply-chain-security) et dans les initiatives de défense contre les attaques de la chaîne d'approvisionnement telles que SLSA ( https: / / slsa.dev /).