En bref

  • 42 dépôts GitHub authentiques ont été compromis avec un malware de 13 Mo, invisible pour la recherche de code GitHub.
  • Le code malveillant se déclenche au démarrage d'une session Claude Code, Gemini CLI, Cursor ou VS Code via les fichiers de configuration du projet.
  • Auditez immédiatement les fichiers .claude/settings.json, .gemini/settings.json, .cursor/mcp.json et .vscode/tasks.json dans vos dépôts récemment clonés.

Comment 42 dépôts GitHub sont devenus des pièges à développeurs

Les chercheurs de JFrog Security Research ont rendu publique, le 26 octobre 2026, la découverte d'une campagne d'attaque sophistiquée ciblant directement les développeurs qui utilisent des assistants IA pour coder. Quarante-deux dépôts GitHub authentiques appartenant à onze propriétaires légitimes — des développeurs individuels, des étudiants et au moins une entreprise — ont été compromis et transformés en pièges actifs. Le malware injecté se déclenche au moment précis où un développeur ouvre le projet dans Claude Code, Gemini CLI, Cursor ou VS Code. La campagne, baptisée « testmetest » par les chercheurs, représente une évolution majeure dans les menaces de chaîne d'approvisionnement visant l'écosystème du développement assisté par IA.

La technique employée est remarquablement ingénieuse dans sa capacité à contourner les mécanismes de détection natifs de GitHub. L'attaquant, opérant sous le compte GitHub « CementBeetleSteeple », a injecté dans chaque dépôt compromis un fichier malveillant nommé .github/init.js. Ce fichier présente une particularité délibérée : sa taille, comprise entre 12,9 Mo et 13,7 Mo, dépasse exactement le seuil au-delà duquel GitHub ne l'indexe pas dans son moteur de recherche de code. La Content API de GitHub ne retourne pas non plus les fichiers dépassant cette limite, rendant le payload pratiquement invisible lors d'une inspection superficielle des sources du dépôt.

Le mécanisme de déclenchement exploite les fichiers de configuration propres à chaque outil IA. Pour Claude Code, le fichier .claude/settings.json est modifié pour invoquer le script au démarrage d'une session. Pour Gemini CLI, c'est .gemini/settings.json qui sert de vecteur. Cursor est ciblé via .cursor/mcp.json et .cursor/rules/setup.mdc, tandis que VS Code est piégé par une modification de .vscode/tasks.json. Ces fichiers de configuration sont souvent ignorés par les développeurs qui clonent un dépôt : ils paraissent anodins, mais ils s'exécutent automatiquement, sans invite de commande ni avertissement visible dans l'interface de l'outil.

Les quarante-deux dépôts appartiennent à onze propriétaires distincts, ce qui indique que l'attaquant a préalablement compromis les comptes GitHub de ces propriétaires — probablement via des tokens d'accès personnels volés ou des mots de passe réutilisés — avant de pousser les modifications malveillantes. Les propriétaires eux-mêmes n'avaient vraisemblablement pas connaissance de la compromission de leurs comptes. Cette approche, qui consiste à « emprunter » la légitimité de dépôts existants plutôt que d'en créer de nouveaux, augmente considérablement le taux de succès : un développeur est bien plus susceptible de cloner un dépôt d'un compte actif depuis plusieurs années qu'un dépôt fraîchement créé.

L'investigation de JFrog révèle que cette attaque est le prolongement d'une campagne npm plus large identifiée précédemment sous le même nom de code « testmetest ». Des packages npm malveillants liés à cette campagne avaient déjà été signalés au registre npm. L'extension aux fichiers de configuration des outils IA représente une escalade stratégique : là où le vecteur npm ciblait les développeurs lors de l'installation de dépendances, le vecteur GitHub ciblé sur les assistants IA atteint les développeurs dès l'ouverture d'un projet, avant même qu'ils n'aient exécuté la moindre commande.

La charge malveillante précise du fichier .github/init.js n'a pas été entièrement publiée par JFrog, pour éviter de faciliter le travail des imitateurs. Les comportements observés correspondent toutefois à un stealer polyvalent : exfiltration des variables d'environnement contenant des clés API (notamment ANTHROPIC_API_KEY, GEMINI_API_KEY, OPENAI_API_KEY), récupération des clés SSH présentes dans ~/.ssh/, et exfiltration potentielle des credentials stockés dans les gestionnaires de mots de passe CLI. Ces informations permettraient à l'attaquant de pirater les comptes cloud des développeurs, d'utiliser leurs quotas API à leurs frais, ou de compromettre leur infrastructure de déploiement.

GitHub a été notifié et a procédé à la suppression des dépôts compromis ainsi qu'à la suspension du compte « CementBeetleSteeple ». Les onze propriétaires de comptes touchés ont reçu des notifications. Cependant, les dépôts existaient depuis plusieurs semaines avant leur détection, laissant une fenêtre d'exposition non négligeable. JFrog estime que le nombre de développeurs ayant cloné un ou plusieurs des dépôts piégés se situe dans une fourchette de plusieurs centaines à quelques milliers, en se basant sur les statistiques de clonage partiellement accessibles.

La technique des fichiers surdimensionnés pour échapper à l'indexation constitue une innovation défensive préoccupante. Elle démontre une connaissance précise des limitations des outils de visibilité de GitHub. Des commandes simples comme find . -name "*.js" -size +10M ou l'inspection du répertoire .github/ avec ls -lh restent efficaces pour détecter des fichiers suspects, mais ces vérifications ne font pas partie des réflexes habituels lors du clonage d'un dépôt externe.

Quand les outils IA deviennent un vecteur d'attaque de première classe

Cette attaque illustre une tendance de fond dans le paysage des menaces : les acteurs malveillants s'adaptent avec une rapidité croissante à l'adoption massive des outils de développement assisté par IA. Depuis que Claude Code, Gemini CLI, GitHub Copilot et Cursor se sont imposés dans les équipes de développement, ils sont devenus des vecteurs d'attaque à part entière. La présence de fichiers de configuration dans les dépôts Git est une conséquence naturelle du travail collaboratif — les développeurs partagent leurs configurations pour harmoniser les environnements — mais cette pratique crée une surface d'attaque que les adversaires exploitent désormais activement et méthodiquement.

L'industrie de la sécurité avait déjà documenté les risques des fichiers AGENTS.md weaponisés, où des instructions malveillantes détournaient le comportement d'agents IA pour exfiltrer des données ou déclencher des actions non autorisées. Cette nouvelle campagne va plus loin dans la radicalité de l'approche : au lieu de manipuler les instructions d'un agent, elle exécute directement du code arbitraire au niveau du shell, avant même que l'assistant ne soit pleinement initialisé. C'est une évolution du vecteur qui ne nécessite aucune interaction avec l'agent IA lui-même.

Pour les équipes de développement, l'impact potentiel dépasse la compromission d'un seul poste de travail. Les développeurs qui utilisent des assistants IA disposent généralement de clés API à forte valeur économique, de tokens d'accès aux registres de containers, de credentials Kubernetes, et parfois d'accès direct aux pipelines CI/CD. Un seul poste compromis peut servir de pivot vers l'ensemble de la chaîne de livraison logicielle d'une organisation. Dans un contexte de développement agile où les développeurs clonent régulièrement des dépôts externes pour s'en inspirer ou les tester, cette surface d'exposition est structurellement difficile à réduire.

Sur le plan réglementaire, cet incident renforce les arguments pour une inclusion explicite des outils IA de développement dans les politiques de sécurité des organisations. La directive NIS2, applicable aux entités essentielles et importantes en Europe, impose une gestion des risques de la chaîne d'approvisionnement ; les outils de développement assisté par IA et leurs fichiers de configuration associés entrent pleinement dans cette catégorie de risque tiers. Les RSSI devraient, à la lumière de cet incident, imposer une politique systématique de vérification des fichiers de configuration avant tout clonage de dépôt externe, et envisager l'utilisation de solutions de détection basées sur le comportement pour les postes de développeurs.

Ce qu'il faut retenir

  • 42 dépôts GitHub légitimes ont été weaponisés avec un malware de 13 Mo indétectable par la recherche de code GitHub, actif depuis plusieurs semaines avant sa découverte.
  • Le déclenchement se fait automatiquement via les fichiers de configuration de Claude Code, Gemini CLI, Cursor et VS Code, sans action explicite du développeur.
  • Exécutez find . -name "init.js" -size +10M dans vos répertoires de projets et auditez l'intégrité de vos fichiers de configuration d'outils IA.

Comment savoir si j'ai cloné un dépôt compromis ?

Vérifiez la présence d'un fichier .github/init.js de taille supérieure à 10 Mo dans vos dépôts avec la commande find . -name "init.js" -size +10M. Si vous en trouvez un, ne l'exécutez pas, révoquez immédiatement toutes les clés API présentes dans vos variables d'environnement sur les postes concernés, et signalez l'incident à votre équipe sécurité.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact