Quand des commandes CLI anodines se composent en exploit dans les agents de code

De quoi s’agit-il ?

Le 3 juillet 2026, des chercheurs de l’université Sun Yat-sen et de collaborateurs des universités de Shandong, de Pékin et de HKUST ont publié un article arXiv décrivant une surface de risque négligée dans les agents de code fondés sur des LLM. Les agents de code modernes — Claude Code, Codex CLI, Gemini CLI et outils similaires — travaillent de plus en plus en émettant de simples commandes en ligne de commande : ils clonent des dépôts, lisent des fichiers, installent des dépendances, lancent des tests, éditent la configuration et committent des changements. Fidèles à la philosophie Unix, ces commandes coopèrent via un état système partagé : une commande peut écrire un état qu’une commande ultérieure relira. La contribution de l’article est de nommer et de mesurer ce qui arrive lorsqu’on détourne cette coopération : une suite de commandes individuellement anodines peut se composer en une capacité bien au-delà de la tâche demandée. Les auteurs appellent cela le risque de composition de commandes CLI (CCR), et montrent que les agents actuels y sont largement exposés.

Comment ça marche

Presque tous les travaux antérieurs sur la sécurité des agents de code étudient la couche d’instruction : un texte adverse placé dans un fichier, une page web, un ticket ou une sortie d’outil, qui tente d’orienter le modèle vers une action nuisible. Les défenses vivent à la même couche — filtrage de prompt, structuration des entrées, isolation, ou contrôles à l’exécution vérifiant si l’appel d’outil proposé correspond à l’intention de l’utilisateur. Toutes partagent une hypothèse implicite : le signal d’attaque est visible dans une entrée, une réponse ou une action isolée.

Le CCR brise cette hypothèse. L’article modélise l’exécution d’un agent comme une trace de commandes à état — chaque commande est une transition sur un état local qui inclut les variables d’environnement, les fichiers de l’espace de travail, la configuration du dépôt, les scripts de cycle de vie de paquets et les hooks. Le signal malveillant n’apparaît dans aucune commande isolée. Il réside dans une relation producteur–consommateur entre étapes anodines : une commande écrit légitimement un état, une commande ultérieure le consomme légitimement, et l’effet combiné atteint quelque chose de sensible. Une barrière d’approbation locale qui inspecte la chaîne de la commande courante ne peut pas voir l’état caché qu’une commande produit ou consomme ; la trace composée passe donc au travers.

Le cas illustratif de l’article est le motif du chemin des hooks git, déjà documenté publiquement dans des avis de sécurité sur les agents de code : un dépôt contrôlé par l’attaquant demande à l’agent, via son README, d’exécuter une étape d’installation d’une ligne qui redirige le répertoire des hooks de git vers le dépôt ; le commit ultérieur et routinier de l’agent relit alors cette configuration et exécute le hook planté dans le contexte de l’agent, aboutissant à l’exécution de code. Aucune des deux commandes n’est malveillante en soi. Pour faire émerger de tels cas à l’échelle, les chercheurs ont construit un cadre guidé par la connaissance qui distille des comportements commande–état validés à partir de CVE publics, d’avis de mainteneurs et de preuves de concept de chercheurs, les compose en workflows plausibles et teste les agents en boîte noire. Cet article mesure une classe de risque existante bâtie sur des connaissances déjà publiques, ce n’est pas un nouvel exploit.

Pourquoi c’est important

Sur cinq agents de code CLI réels et cinq modèles de fond, à travers 2 525 essais, les attaques par composition atteignent un taux de succès de bout en bout de 96,59 % sous des tâches de développement d’apparence anodine, quand les lignes de base à la couche d’instruction plafonnent autour de 2,18 %. La base de connaissances structurée compte : elle produit plus de 50 % de cas efficaces en plus qu’un générateur de modèle autonome. Comme le substrat CLI atteint directement la machine du développeur et l’environnement de production, l’impact n’est pas théorique — la même classe de composition peut effacer des données, exfiltrer du code source et des identifiants, empoisonner une chaîne d’approvisionnement en aval, planter des portes dérobées persistantes ou rebondir vers des systèmes internes.

Le constat le plus tranchant est défensif. Les auteurs ont évalué cinq défenses déployées représentatives et ont trouvé qu’aucune n’observait le risque de composition, parce que chacune raisonne sur une commande ou une action isolée plutôt que sur les relations d’état à travers la trace. C’est là le fossé structurel : l’unité de risque pertinente est la trace de commandes entière, mais les contrôles en production jugent encore les commandes une à une.

Défenses

Le changement pratique consiste à cesser de traiter chaque chaîne de commande comme l’unité de sécurité et à suivre la provenance de l’état à travers la trace. Instrumentez l’agent pour qu’il enregistre l’état que chaque commande produit et consomme — variables d’environnement, configuration git et d’outils, hooks, scripts de cycle de vie de paquets — et ajoutez de la friction lorsqu’une commande ultérieure sensible à la sécurité consomme un état écrit à partir de contenu non fiable, tel qu’un dépôt cloné ou une page récupérée. Contrôlez les consommateurs, pas seulement les producteurs : un commit, une installation ou un test qui dépend d’une configuration écrite par une étape antérieure à partir d’entrées non fiables mérite une revue, même si chaque commande paraît routinière.

Réduisez l’autorité permanente dont dépend la capacité composée. Exécutez les agents de code dans un bac à sable sans accès aux identifiants réels ni aux systèmes de production, et désactivez par défaut les surfaces d’exécution automatiques — épinglez ou ignorez les chemins de hooks git, sautez les scripts de cycle de vie de paquets (par exemple avec la suppression des scripts à l’installation) et isolez la configuration que l’agent peut modifier. Ajoutez une approbation humaine aux frontières de trace où l’état produit change la sémantique d’exécution ultérieure. Enfin, menez des exercices de red team sur les agents de code avec des cas de composition multi-commandes, et pas seulement de l’injection à la couche d’instruction, en alignant les contrôles sur la direction proposée par l’article : une défense sensible à la provenance qui raisonne sur les relations d’état à travers la trace plutôt que d’inspecter des actions isolées.

Statut

Élément	Détail
Contribution	Nomme et mesure le risque de composition de commandes CLI (CCR) dans les agents de code
Méthode	Cadre guidé par la connaissance distillant le comportement commande–état depuis CVE, avis et PoC publics
Évaluation	5 agents de code CLI · 5 LLM de fond · 2 525 essais
Succès d’attaque	96,59 % de bout en bout sous tâches anodines · lignes de base couche d’instruction ≤ 2,18 %
Défenses déployées	5 défenses représentatives testées — aucune n’observe le risque de composition
Direction proposée	Défense sensible à la provenance sur la trace de commandes
Cas réel	Composition RCE via chemin de hooks git dans un IDE-agent de code — CVE-2026-26268

Date clé : article publié sur arXiv le 3 juillet 2026.