Quand un prompt ouvre un shell : la RCE par injection dans les agents IA

L'injection de prompt a longtemps été présentée comme un problème de confidentialité : un attaquant glisse des instructions cachées pour faire fuiter des données ou détourner une réponse. La recherche publiée par Microsoft le 7 mai 2026 change la nature du risque. Dans un cadriciel d'agents IA très répandu, Semantic Kernel, une simple injection de prompt peut être transformée en exécution de code à distance sur l'hôte qui fait tourner l'agent. La démonstration de l'équipe de recherche Defender est frappante : une seule injection dans un agent de recherche d'hôtels, et calc.exe s'ouvre sur la machine exécutant le processus de l'agent. Pas d'exploit navigateur, pas de pièce jointe malveillante, pas de corruption mémoire. Un prompt.

Cet incident marque un tournant que toute organisation déployant des agents IA doit intégrer, et il n'est pas isolé : l'OWASP a publié en décembre 2025 son Top 10 pour les applications agentiques, reconnaissant que cette classe de menace est devenue centrale.

Comment un prompt devient une exécution de code

Deux vulnérabilités distinctes ont été divulguées. CVE-2026-26030, notée CVSS 9.8, achemine des champs de magasin de vecteurs contrôlés par l'attaquant vers un appel Python eval(). CVE-2026-25592 expose une méthode de téléchargement de fichier côté hôte comme fonction appelable par le noyau de l'agent. Le premier cas est le plus instructif pour comprendre le mécanisme.

Le cadriciel effectue bien une validation par arbre syntaxique du contenu avant de l'évaluer, et bloque certains identifiants et attributs dangereux. Mais les attaquants ont contourné ces restrictions en utilisant des techniques de parcours de la hiérarchie de classes Python, ce qui leur a permis de charger dynamiquement le module os et d'exécuter des commandes système. Autrement dit, la barrière de sécurité, une liste noire d'identifiants, a été franchie par un chemin indirect que la liste ne couvrait pas. C'est un rappel classique : filtrer par liste noire ce qui peut atteindre un évaluateur de code est presque toujours contournable.

La leçon d'architecture est que le registre d'outils est la surface d'attaque. Dès qu'un agent peut appeler des fonctions, et que le contenu qu'il traite peut influencer quelle fonction est appelée et avec quels arguments, une injection de prompt bien construite devient un appel de fonction non prévu. Quand l'une de ces fonctions atteint un évaluateur de code ou une primitive système, l'injection devient une RCE.

Red teaming : comment tester ses propres agents

La détection réactive ne suffit pas pour cette classe de faille : il faut tester ses agents avant qu'un attaquant ne le fasse. Un exercice de red teaming d'agent IA doit couvrir plusieurs axes.

Premièrement, l'injection indirecte via les données. Placez des instructions malveillantes dans les sources que l'agent lit sans que l'utilisateur les ait tapées : documents indexés, résultats de recherche, descriptions d'outils, champs d'un magasin de vecteurs. C'est le vecteur exact de CVE-2026-26030. Vérifiez si un contenu de données peut influencer l'appel d'un outil.

Deuxièmement, l'inventaire des outils dangereux. Recensez toutes les fonctions exposées à l'agent et repérez celles qui atteignent, directement ou par transitivité, un évaluateur de code, un accès au système de fichiers, un lancement de processus ou une requête réseau sortante. Ce sont les cibles de l'escalade vers la RCE.

Troisièmement, le test de contournement des filtres. Si votre agent s'appuie sur une liste noire pour bloquer certains identifiants ou motifs, tentez explicitement les parcours de hiérarchie de classes et les constructions indirectes, car c'est précisément ce qui a fonctionné contre Semantic Kernel.

Les principes de conception qui referment la faille

Au delà des correctifs, dont l'application est prioritaire, plusieurs principes réduisent structurellement le risque. Le premier est de ne jamais router du contenu contrôlable vers un évaluateur de code dynamique : préférer un ensemble de fonctions explicitement autorisées, à arguments typés, plutôt qu'un eval() protégé par liste noire. Le second est le moindre privilège appliqué aux outils : l'agent ne doit disposer que des fonctions strictement nécessaires à sa tâche, et ces fonctions doivent s'exécuter dans un contexte isolé, sans accès direct à l'hôte. Le troisième est la validation des arguments à la frontière de chaque outil, indépendamment de ce que le modèle a décidé.

Microsoft a livré les correctifs dans semantic-kernel version 1.39.4 pour Python et 1.71.0 pour .NET. Mais le correctif ne dispense pas de l'exercice de fond : tout agent capable d'appeler des outils hérite de cette classe de risque, quel que soit le cadriciel utilisé.

Tester la robustesse d'un agent IA face à l'injection de prompt et à l'escalade vers la RCE demande une méthodologie et un outillage dédiés. C'est ce que fournit le feed LLM red team ThreatClaw : des cas de test et des sondes construits sur les techniques d'attaque réelles contre les agents et leurs registres d'outils, pour éprouver vos déploiements avant qu'un attaquant ne s'en charge.