Un dépôt qui paraît parfaitement inoffensif peut suffire à faire exécuter un malware par un agent de codage IA, sans alerter ni les outils de sécurité ni un relecteur humain. Le scénario, décrit par BleepingComputer, concerne un outil agentique chargé d’ouvrir un repository GitHub d’apparence bénigne, mais capable d’exécuter une charge malveillante invisible dans une revue de code classique.
Le principe est simple. Le dépôt n’a pas besoin de sembler compromis au premier coup d’œil. Si l’attaque est dissimulée dans la manière dont l’agent récupère, interprète ou lance le projet, un contrôle manuel passe à côté. Entre « consulter un dépôt » et « exécuter ce que le dépôt demande », la frontière devient un angle d’attaque à part entière.
Points clés
- Un agent de codage IA peut exécuter une charge malveillante en ouvrant un dépôt GitHub d’apparence bénigne, sans alerter la revue de code.
- Début juin, GitHub a désactivé 73 dépôts Microsoft après une compromission liée au ver Miasma visant Claude Code, Gemini CLI, VS Code et Cursor.
- L’attaque se loge dans les fichiers de configuration, règles d’agent ou consignes que l’outil traite comme fiables.
- Parades : limiter les droits de l’agent, exiger une validation humaine avant exécution et séparer lecture et lancement d’un dépôt.
Quand l’agent de code devient la cible
Les assistants de développement IA ne se contentent plus de compléter du code. Ils explorent des dépôts, analysent les dépendances, lisent les fichiers de configuration et suivent parfois des consignes pour préparer un projet ou lancer un test. C’est ce comportement qui peut être détourné. Un dépôt soigneusement préparé paraît inoffensif pour un humain tout en guidant l’agent vers l’exécution d’un binaire, d’un script ou d’une commande piégée.
Des incidents récents vont dans le même sens. Début juin, GitHub a désactivé 73 dépôts Microsoft après une compromission liée au ver Miasma, qui visait des outils de codage IA comme Claude Code, Gemini CLI, VS Code et Cursor. La chaîne d’attaque exploitait des fichiers de configuration ou d’instructions destinés aux assistants pour déclencher une exécution automatique à l’ouverture d’un projet.
Cette catégorie d’attaque n’implique pas forcément une dépendance compromise ou un paquet piégé. Elle peut se loger dans des fichiers de projet, des règles d’agent, des hooks ou des consignes que l’outil traite comme fiables. Pour un développeur, le réflexe change. Ouvrir un dépôt dans un environnement agentique peut suffire à activer un comportement non souhaité.
Une surface d’attaque élargie par les workflows agentiques
Le risque ne se limite pas aux humains qui lancent un script sans vérifier. Les workflows pilotés par IA multiplient les interactions automatiques avec GitHub et d’autres sources de code. L’agent cherche des exemples, résout une dépendance, compare des implémentations ou prépare un environnement sans validation visuelle à chaque étape. Un dépôt d’apparence « propre » peut ainsi être sélectionné, ouvert et exécuté à la vitesse d’une requête.
Les défenseurs ont déjà vu se multiplier des variantes de la même logique. Des chercheurs ont documenté des attaques par empoisonnement d’instructions d’agent, des fichiers de règles invisibles et des payloads cachés dans des ressources auxiliaires. Le dénominateur commun reste identique. Il s’agit d’exploiter la confiance que l’outil accorde au contenu du dépôt, alors que cette confiance devrait rester conditionnelle.
Les mesures de prudence sont concrètes. Limiter les droits de l’agent, exiger une validation humaine avant toute exécution locale, séparer la lecture d’un dépôt de son lancement et traiter comme non fiable tout contenu récupéré automatiquement depuis une source externe. Dans les environnements où l’assistant peut lancer des commandes, le dépôt n’est plus un simple objet de lecture. Il devient une surface d’exécution.
