GuardFall : les garde-fous des agents de code inspectent un texte que le shell réécrit

De quoi s’agit-il ?

Le 30 juin 2026, Adversa AI a publié GuardFall, une étude sur la façon dont les agents de code IA open source décident si une commande shell peut être exécutée sans danger. L’entreprise a testé onze agents de code et d’usage-ordinateur open source populaires et a trouvé la même faiblesse dans dix d’entre eux ; un seul, Continue, était conçu pour y résister. La couverture a suivi chez The Hacker News, SecurityWeek et SC Media.

Il ne s’agit pas d’un bug isolé dans un produit. Adversa qualifie le phénomène de « convention dangereuse et classe de problèmes » — c’est pourquoi il n’existe aucun identifiant unique à suivre ou à corriger. Les agents protègent l’exécution shell en comparant chaque commande à une liste noire de motifs dangereux, en tant que texte brut. Le shell réécrit ensuite ce même texte — suppression des guillemets, expansion des raccourcis — avant de l’exécuter. Le filtre et le shell examinent deux chaînes différentes. C’est le même décalage inspection-exécution qui alimente l’injection SQL et l’injection shell classique depuis des décennies, réapparu dans le runtime des agents.

C’est un proche cousin du contournement de liste de blocage shell de l’agent Microsoft : une liste noire qui raisonne sur la mauvaise représentation de la commande.

Comment ça marche

Un agent qui protège en comparant du texte brut vérifie une représentation que le système d’exploitation n’exécute jamais réellement. L’écart se voit le mieux avec la suppression des guillemets : un filtre qui surveille une commande de suppression destructrice ne voit rien d’anormal dans une variante où des guillemets vides sont insérés entre deux lettres, car pour un comparateur de texte ce sont des chaînes différentes. Bash supprime les guillemets vides et exécute quand même la commande d’origine.

Le garde-fou inspecte :   r''m  -rf  <chemin>   -> aucune correspondance ("rm" absent en texte)
Bash exécute :            rm    -rf  <chemin>   -> guillemets retirés, la vraie commande s'exécute

Aucune charge fonctionnelle n’est reproduite ici — le point est structurel, et ces particularités du shell sont de notoriété publique depuis des décennies. La même idée se généralise : une commande dissimulée dans un blob base64 puis redirigée vers un shell, ou un outil ordinaire et autorisé (un chercheur de fichiers, un utilitaire disque) rendu destructeur avec le bon drapeau. Ajouter des entrées à la liste noire ne corrige rien, car le garde-fou raisonne sur le mauvais artefact.

Deux conditions doivent se réunir, et aucune n’est exotique :

• Le modèle doit émettre la commande. Une demande directe de tout supprimer est généralement refusée, mais la même instruction glissée dans un travail de routine — un fichier de build, ou la réponse « documentation » d’un outil que l’agent lit en cours de tâche — est émise comme une étape ordinaire. C’est l’injection de prompt indirecte qui fournit la charge.
• L’agent doit s’exécuter sans surveillance, avec un drapeau d’auto-exécution activé ou le bac à sable du conteneur désactivé — deux configurations courantes dans les pipelines automatisés. Les tests en direct d’Adversa utilisaient Claude Sonnet 4.6.

Les dix outils qui laissaient l’écart ouvert étaient opencode, Goose, Cline, Roo-Code, Aider, Plandex, Open Interpreter, OpenHands, SWE-agent et le projet Hermes, où le problème est d’abord apparu. Ensemble, les outils étudiés totalisaient environ 548 000 étoiles GitHub en mai 2026. Adversa a démontré l’attaque de bout en bout contre le binaire Plandex de production et a constaté que la même forme fonctionnait contre huit autres. L’entreprise décrit ce travail comme de la recherche en laboratoire ; aucune exploitation publique n’a été signalée.

Pourquoi c’est important

Ces agents exécutent des commandes shell avec l’ensemble des privilèges du compte du développeur. Dirigez-en un vers un dépôt ou une dépendance piégés, et une instruction cachée peut discrètement lancer une commande qui efface des fichiers ou atteint tout ce que le compte peut atteindre — clés SSH, identifiants cloud, tout ce qui se trouve dans le répertoire personnel. La condition préalable est une habitude quotidienne de développeur : cloner un projet inconnu, laisser l’agent y travailler. Cela en fait une voie d’attaque de chaîne d’approvisionnement crédible, de la même famille qu’AutoJack et Agentjacking, où un contenu non fiable devient une commande que l’agent exécute avec les droits de son propriétaire. Le fil conducteur : du texte non fiable atteint un vrai shell avant que le garde-fou ne comprenne ce que bash va réellement faire.

Défenses

Le correctif durable est architectural, et un outil testé le démontre déjà.

1. Protéger la commande exécutée, pas le texte. Continue a tenu bon parce qu’il lit la commande comme le fera bash avant de décider : il découpe et développe la chaîne dans les mêmes fragments que le shell produirait, vérifie ce qui s’exécute réellement, et conserve une liste stricte de commandes destructrices bloquées d’emblée. Adversa juge le design portable et estime sa réimplémentation à environ deux jours-ingénieur. Analyser-puis-vérifier, jamais comparer-le-texte-brut.

2. Préférer les listes blanches aux listes noires. Une liste de blocage de motifs « dangereux » est un combat perdu face à la réécriture shell. Autorisez un petit ensemble de commandes sûres connues et refusez le reste, évalué après expansion.

3. Neutraliser le rayon d’impact. Pointez $HOME vers un répertoire jetable afin que des secrets comme ~/.ssh et ~/.aws soient hors de portée, et gardez le bac à sable du conteneur actif. Si la commande échappe au garde-fou, elle ne doit atterrir nulle part d’utile.

4. Ne pas exécuter sans surveillance sur des entrées non fiables. Désactivez les drapeaux d’auto-exécution (--auto-exec, --auto-run, --auto-test, dangerously-skip-permissions) sauf si la tâche ne peut vraiment pas s’interrompre pour un humain, et ne lancez jamais un agent sur des pull requests issues de forks — le chemin le plus court entre le fichier d’un attaquant et vos secrets.

5. Traiter la configuration livrée dans le dépôt comme du code non fiable. Un fichier de configuration commité dans un dépôt (par exemple .aider.conf.yml) peut orienter l’agent dès la première modification acceptée. Relisez-le avant que l’agent n’agisse dessus.

Statut

Élément	Référence	Date	Notes
Divulgation GuardFall	Adversa AI	2026-06-30	Convention de classe ; aucun CVE unique attribué
Périmètre testé	Adversa AI	2026-06	11 agents open source ; 10 vulnérables, Continue résistant
Démo de bout en bout	Adversa AI	2026-06	Binaire Plandex de production ; recherche en labo, aucune exploitation publique
Contournements liés	LLM Hacking	2026	Contournement de liste de blocage shell, AutoJack, Agentjacking — même écart inspection/exécution

Le cadrage honnête n’est pas « un outil IA a un bug » — c’est qu’un garde-fou qui inspecte le texte d’une commande ne peut pas sécuriser un shell qui réécrit ce texte avant de l’exécuter. Tant que les agents n’analysent pas les commandes comme le fait le shell, la défense vous revient : vérifiez la commande exécutée, préférez les listes blanches, isolez le runtime et gardez un humain dans la boucle sur tout ce qui n’est pas fiable.