L'outil shell de MS-Agent : une denylist regex transforme l'injection de prompt en RCE

De quoi s’agit-il ?

CVE-2026-2256 est une faille d’injection de commande dans MS-Agent de ModelScope, un framework open source de construction d’agents IA outillés. Elle a été divulguée via la note de vulnérabilité CERT/CC VU#431821, publiée le 2 mars 2026, et signalée par le chercheur Itamar Yochpaz. ModelScope a été notifié le 15 janvier 2026 ; selon le CERT/CC, aucun correctif ni déclaration de l’éditeur n’a été obtenu durant la coordination. SentinelOne situe la plage affectée à v1.6.0rc1 et antérieures et classe le problème en CWE-77 (injection de commande).

Le point notable n’est pas qu’un framework d’agents comporte une RCE. C’est comment le bug est atteint : non pas par un opérateur tapant une commande malveillante, mais par du contenu non fiable — un document, un dépôt de code, un log, une entrée de recherche — qui pousse l’agent à en exécuter une. C’est une injection de prompt indirecte qui aboutit à un véritable shell.

Comment ça marche

MS-Agent fournit un outil Shell qui permet à un agent d’exécuter des commandes système pour accomplir des tâches. L’outil tente d’être sûr : une méthode check_safe() filtre les commandes dangereuses. Le problème est comment il filtre — avec une denylist par expression régulière.

Les denylists pour entrées shell sont une impasse bien connue. Il existe trop de façons d’exprimer le même effet : encodage, obfuscation de commande, syntaxe shell alternative, interpréteurs de confiance et simple sémantique de parsing du shell offrent tous des chemins que le motif n’a jamais anticipés. La note du CERT/CC est sans détour : « Le filtrage par denylist est intrinsèquement fragile et peut souvent être contourné par l’encodage, l’obfuscation de commande ou une syntaxe shell alternative. »

La chaîne d’attaque est la suivante :

contenu non fiable (doc / dépôt / log / résultat web)
        │  contient du texte qui oriente l'agent…
        ▼
l'agent décide d'utiliser l'outil Shell
        │  construit une chaîne de commande contenant le texte sous influence
        ▼
denylist regex check_safe()  ──►  [CONTOURNÉE]
        │
        ▼
le shell exécute la chaîne avec les privilèges du processus de l'agent

Aucun payload n’est reproduit ici. C’est la forme qui compte : l’agent assemble et soumet lui-même la commande dans son flux d’exécution normal, il n’y a donc aucun « abus opérateur » à incriminer. Le filtre voit une chaîne qu’il a jugée bénigne ; le shell voit de la logique exécutable.

Pourquoi c’est important

Une fois la denylist contournée, l’attaquant exécute des commandes avec les privilèges du processus MS-Agent. Le CERT/CC et le signalement décrivent le rayon d’impact réaliste : lecture de secrets (clés d’API, jetons, fichiers de configuration) ; dépôt de payloads ; modification de l’état du workspace ; établissement de persistance ; pivot vers des services internes ; et empoisonnement de sorties de build ou de rapports consommés en aval.

Une remarque sur le scoring : SentinelOne indique un CVSS de 6,5 (moyen), avec un impact faible en confidentialité et intégrité dans le vecteur. Traitez cela comme un plancher, pas un plafond. Les métriques de base CVSS ne capturent pas le contexte agentique — un agent qui ingère du contenu externe et détient des secrets est précisément le montage de la « triade létale » (données privées + entrée non fiable + capacité d’agir), et là le résultat pratique évolue vers la compromission de l’hôte. La note « moyen » reflète une vue technique étroite ; la réalité de déploiement est plus grave.

La leçon plus large dépasse largement MS-Agent. Tout agent qui expose un outil shell, d’exécution de code ou de fichiers, et tente de le sécuriser en bloquant les chaînes connues comme mauvaises, répète cette erreur. Les frontières d’appel d’outil relèvent d’un problème d’autorisation, pas de correspondance de motifs.

Défenses

1. Remplacez les denylists par des allowlists. N’essayez pas d’énumérer les commandes dangereuses. Énumérez le petit ensemble d’opérations autorisées et rejetez tout le reste. C’est le seul changement qui corrige la classe de bug, pas juste un contournement.
2. Évitez shell=True. Lorsqu’un outil shell est inévitable, exécutez des vecteurs d’arguments directement (sans interprétation par le shell) afin que la sémantique de parsing ne puisse pas être transformée en injection. Ne concaténez jamais du texte dérivé du modèle ou du contenu dans une chaîne shell.
3. Sandboxez l’outil et appliquez le moindre privilège. Exécutez les agents dotés de capacité shell dans un conteneur avec capacités retirées, système de fichiers en lecture seule, no-new-privileges et un profil MAC (AppArmor/SELinux). Si le processus ne peut pas lire vos secrets, un contournement ne peut pas les exfiltrer.
4. Considérez tout contenu ingéré comme non fiable. Documents, dépôts, logs et résultats web sont contrôlés par l’attaquant par défaut. N’exécutez MS-Agent que sur du contenu que vous faites confiance, validez ou assainissez — exactement ce que recommande l’avis du CERT/CC.
5. Brisez la triade létale. Ne réunissez pas l’accès aux données privées, l’entrée non fiable et un outil capable d’agir dans un seul agent non supervisé. Séparez les privilèges, ou conditionnez les appels d’outils à une validation humaine ou de politique.
6. Surveillez le contournement. Journalisez les chaînes de commande soumises par l’agent et alertez sur les métacaractères shell (;, |, &&, $(), backticks), les processus enfants inattendus engendrés par l’agent et les appels de type execve() aux arguments suspects.

État des lieux

Élément	Référence	Date	Notes
CVE-2026-2256	VU#431821	2026-03-02	Injection de commande dans l’outil Shell de MS-Agent via contournement de la denylist check_safe()
Versions affectées	SentinelOne	2026-03	ModelScope ms-agent v1.6.0rc1 et antérieures ; CWE-77 ; CVSS 6,5 (moyen)
Réponse de l’éditeur	VU#431821	2026-03-02	Notifié le 2026-01-15 ; aucune déclaration ni correctif obtenu durant la coordination

À retenir pour les développeurs : un outil shell protégé par une denylist regex n’est pas protégé. Si votre agent peut exécuter des commandes, la frontière que vous contrôlez réellement, ce sont les privilèges du processus et la fiabilité de ce qu’il lit — concevez ces éléments, et partez du principe que le filtre de chaînes échouera.