GuardFall : dix agents de codage IA sur onze cèdent à de vieilles astuces du shell

Le filtre lit la commande, Bash en exécute une autre

Le 30 juin 2026, la société de recherche en sécurité Adversa AI a passé au crible onze des agents de codage IA open source les plus répandus, ces assistants autonomes auxquels un développeur délègue la compilation, les tests et la correction de son code. Le verdict est sévère : dix d'entre eux se laissent piéger et exécutent des commandes shell destructrices que leurs propres protections étaient censées bloquer. Un seul, l'agent Continue, tient bon.

Le plus déroutant tient à l'ancienneté du procédé. Les techniques employées figurent dans la littérature de sécurité depuis des décennies, et ce qui est neuf, c'est la cible. Comprendre pourquoi une astuce aussi vieille fonctionne sur un outil aussi récent, voilà tout l'enjeu, car la faille n'est pas le bug d'un produit isolé. C'est un présupposé que partage toute une catégorie de logiciels.

Comment le contournement opère

Adversa a baptisé la faille GuardFall. Chaque agent examiné embarque un outil capable de lancer des commandes shell sur la machine du développeur, une nécessité pour compiler, installer des dépendances ou publier sur git. Comme ce shell hérite de tous les droits du compte utilisateur, avec accès aux clés SSH, aux identifiants cloud et à l'intégralité du répertoire personnel, la plupart des agents placent un garde-fou en amont : un filtre qui inspecte le texte de la commande et rejette ce qui paraît dangereux, par exemple rm -rf /. Le défaut relève d'un décalage connu de longue date : le filtre juge la commande sur son apparence, tandis que Bash, l'interpréteur qui l'exécute réellement, agit sur sa signification une fois la chaîne développée et réécrite. Deux choses distinctes.

Quelques exemples rendent le mécanisme tangible. Écrivez la commande de suppression sous la forme r''m : un filtre qui traque rm n'y voit que deux fragments anodins, mais Bash retire les guillemets vides et lance rm. Remplacez les espaces par $IFS, le séparateur de champs interne du shell, et rm$IFS-rf$IFS/ passe pour un seul mot devant le filtre avant que Bash ne le redécoupe en rm -rf /. Encodez la charge utile en base64 et faites-la transiter par echo ... | base64 -d | sh : chaque maillon paraît inoffensif, la partie destructrice n'existant qu'après décodage. À aucun moment l'attaquant ne touche la machine. Il lui suffit que l'agent lise un texte qu'il contrôle, et c'est là qu'intervient le prompt injection (injection d'invite), qui consiste à dissimuler des instructions dans un contenu que l'assistant traitera comme de simples données.

• Ces instructions se glissent dans un README ou un Makefile piégé, la description d'un paquet sur npm ou PyPI, une page web consultée, ou un serveur MCP malveillant (un connecteur qui alimente l'assistant en résultats d'outils externes).
• Une consigne brutale du type « efface tout » est le plus souvent refusée par le modèle. Le contournement réussit parce que les commandes se présentent comme des étapes de build ordinaires. Les essais grandeur nature d'Adversa reposaient sur Claude Sonnet 4.6, d'Anthropic.
• Le danger se démultiplie en intégration continue (CI, la chaîne automatisée qui compile et teste le code à chaque modification), où les équipes activent des options d'approbation automatique comme --auto-exec pour laisser l'agent tourner sans surveillance, écartant l'humain qui aurait vu passer la commande.

Ce que cela change pour vos équipes

Le résultat concret est une exécution de code à distance (RCE, l'attaquant lance ses propres commandes sur votre système) déclenchée par injection d'invite, et qui ne laisse presque aucune trace. Le garde-fou qui se déclenche sur rm -rf reste muet pendant qu'un simple cp recopie discrètement ~/.aws/credentials ou ~/.ssh/id_rsa vers un emplacement que l'attaquant récupérera. Si vos équipes d'ingénierie ont branché un agent de codage IA sur leur chaîne de build avec l'approbation automatique active, alors une pull request non fiable, ou la simple lecture par l'agent du README d'une dépendance qu'il « étudie », devient une voie directe vers vos secrets cloud et votre code source. Le glissement de fond est plus dérangeant encore. La parade sur laquelle une bonne partie du secteur s'est reposée, une liste noire qui filtre le texte des commandes, ne peut pas tenir, puisqu'elle prétend anticiper le comportement d'un langage conçu précisément pour réécrire ce qu'on lui soumet. Empiler de nouveaux motifs interdits ne bouche aucun trou. Si dix outils sur onze se sont trompés, ce n'est pas par négligence, mais parce que le mauvais modèle mental s'était imposé comme la norme.

Les bons réflexes

1. Coupez l'approbation automatique sur tout agent qui accède à un vrai shell, à des identifiants actifs ou à des données de production. Dès qu'un humain cesse de valider chaque commande, l'injection d'invite se mue en exécution de code silencieuse : conservez la validation manuelle partout où l'agent opère sur un hôte sensible.
2. Faites tourner les agents de codage dans un bac à sable jetable plutôt que sur votre poste de travail. Un conteneur éphémère, privé d'accès à votre répertoire personnel réel et à vos clés cloud, réduit une commande destructrice à un dégât sans lendemain, la seule conception qu'Adversa a jugée véritablement efficace.
3. Traitez le contenu d'un dépôt comme une entrée non fiable, pas comme de la documentation. Un README, un Makefile ou la description d'une dépendance aspirés dans le contexte de l'agent peuvent véhiculer des instructions cachées : isolez l'exécution sur du code inconnu comme vous placeriez en quarantaine un exécutable douteux.

À retenir

GuardFall n'est pas de ces vulnérabilités qu'un correctif referme le mardi suivant. C'est la preuve que la couche de sécurité sur laquelle beaucoup d'équipes s'appuient, un filtre qui lit les commandes comme du texte, n'a jamais été à la hauteur de sa mission. Les deux approches qui ont résisté aux essais d'Adversa sont le bac à sable que l'on peut jeter et le garde-fou qui évalue ce que le shell fera vraiment, et un seul agent répandu proposait le second. La question à porter à votre prochaine revue de sécurité est simple : si demain une instruction hostile se glissait dans un dépôt que lit votre chaîne de build, y aurait-il un humain ou un bac à sable entre cette instruction et vos identifiants, ou seulement un filtre déjà tenu en échec ?