CWE-77 : injection de commande, la classe au-dessus de l’interpréteur système

Vingt-troisième du CWE Top 25 2025, en recul de dix places sur l’édition précédente, le plus fort mouvement du classement, et il s’explique par une correction de méthode plutôt que par un progrès du code. Le libellé officiel est Improper Neutralization of Special Elements used in a Command (‘Command Injection’), « neutralisation incorrecte d’éléments spéciaux utilisés dans une commande ».

→ Lire l’explication complète de la marmotte

Ce que la classe recouvre exactement

Le produit construit tout ou partie d’une commande à partir d’une entrée influencée depuis l’extérieur, sans neutraliser les éléments spéciaux qui pourraient modifier la commande prévue lorsqu’elle est envoyée à un composant en aval.

Le mot décisif est « commande », sans précision du destinataire. C’est ce qui sépare cette classe de sa fille la plus célèbre, l’injection de commande système, au rang 9 : celle-ci restreint au cas où le destinataire est l’interpréteur du système d’exploitation. CWE-77 couvre tous les autres interpréteurs de commandes : un langage d’expression intégré à un cadre applicatif, une expression régulière compilée à l’exécution, un langage de requête maison, une file de tâches dont les messages sont des ordres, et, depuis 2024, les modèles de langage.

Le catalogue accompagne cette entrée d’une note de mappage sans équivoque : usage admis sous réserve de relecture, avec la mention explicite que CWE-77 « est souvent mal employée alors que l’injection de commande système, CWE-78, était visée ». Autrement dit, la plupart des vulnérabilités déclarées sous ce numéro appartenaient à sa fille. Le recul de dix places en 2025 est très probablement l’effet du travail de remappage mené par le MITRE sur un quart des vulnérabilités de la fenêtre d’observation : non pas moins d’injections, mais des injections mieux rangées.

Sa place dans l’arbre

CWE-77 est une classe, fille de CWE-74, le tronc commun des injections. Cinq entrées descendent d’elle, et la liste mérite d’être lue en entier, parce qu’elle montre l’étendue réelle du problème :

CWE-78, l’injection de commande système, la plus connue ;
CWE-88, l’injection de délimiteur d’argument : on n’ajoute pas une commande, on ajoute une option à celle qui était prévue. Un nom de fichier commençant par un tiret peut suffire à changer le comportement du programme appelé ;
CWE-917, l’injection dans un langage d’expression, celui qu’offrent certains cadres applicatifs pour évaluer des expressions dans des gabarits de page ;
CWE-624, l’erreur d’expression régulière exécutable, où le motif lui-même est fourni de l’extérieur ;
CWE-1427, la neutralisation incorrecte d’une entrée utilisée pour inviter un modèle de langage. C’est l’injection de prompt, et son rattachement à cette branche est l’un des choix les plus intéressants du catalogue récent.

L’injection de prompt rangée parmi les injections de commande

Le rattachement de CWE-1427 à CWE-77 dit quelque chose de précis sur la nature du problème, et vaut mieux qu’un débat. La définition du catalogue est la suivante : le produit emploie des données fournies de l’extérieur pour construire les invites envoyées à un modèle de langage, mais la façon dont ces invites sont construites fait que le modèle ne distingue pas les données fournies par l’utilisateur des instructions du développeur.

C’est, mot pour mot, le mécanisme d’une injection : une frontière de langage franchie sans requalification. La différence est qu’ici l’interpréteur en aval n’est pas déterministe, de sorte que la parade usuelle (une séparation syntaxique stricte entre la commande et les données) n’existe pas. Le site traite cette conséquence dans le Top 10 OWASP des applications à modèle de langage et, pour les agents qui agissent, dans le détournement d’objectif de l’agent : quand un contenu lu devient une instruction suivie, on est dans cette classe, et la défense se déplace vers le contrôle de ce que l’agent peut faire plutôt que vers le filtrage de ce qu’il lit.

Pourquoi elle reste au classement

Parce que les interpréteurs applicatifs sont innombrables. Chaque fois qu’un produit offre à ses utilisateurs un langage de règles, de formules ou de filtres, il crée un interpréteur, donc une frontière à défendre. Les plateformes d’automatisation et les outils à faible code multiplient ces frontières par construction.

Parce que la frontière est invisible dans le code. Dans une injection SQL, la requête se voit ; dans une injection de commande applicative, le texte envoyé ressemble à un paramètre ordinaire. Les analyseurs statiques, qui connaissent les interpréteurs standards, ne connaissent pas celui que l’équipe a écrit l’an dernier.

Parce que les nouveaux interpréteurs arrivent plus vite que les défenses. L’entrée CWE-1427 a été créée pour un interpréteur qui n’existait pas cinq ans plus tôt, et dont la propriété essentielle (ne pas distinguer les instructions des données) est contraire à tout ce que la sécurité applicative avait appris à exiger.

Le mécanisme, et où le site le traite

Pour le cas système, la page CWE-78 et écrire des scripts Bash système fiables et sûrs couvrent la matière. Pour le cas du code évalué dans le langage de l’application, l’injection de code est la bonne entrée, et le site traite la question du côté des modèles de documents.

Pour l’interpréteur statistique, valider le function calling d’un LLM décrit le contrôle de ce qui sort du modèle, et l’architecture des guardrails programmatiques celle des garde-fous qui l’encadrent.

Ce qu’une équipe en fait

Préciser l’interpréteur avant de corriger. C’est la conséquence directe de la note de mappage : la question utile est « quel composant en aval reçoit cette commande ? ». La réponse décide de la parade : liste d’arguments pour un programme, requête paramétrée pour une base, séparation stricte pour un moteur de règles, et limitation de pouvoir pour un modèle de langage.

Traiter tout langage de règles comme un interpréteur de production, avec les mêmes exigences qu’un moteur SQL : séparation des instructions et des données, droits réduits, exécution confinée.

Pour les modèles de langage, abandonner l’idée du filtre. Comme aucune séparation syntaxique n’est garantie, la seule défense solide consiste à limiter ce que le système peut faire de la sortie du modèle : valider chaque appel d’outil, exiger une approbation humaine pour les actions irréversibles, et ne jamais accorder à l’agent des droits qu’on ne confierait pas à un inconnu de passage.

Sources

CWE-77: Improper Neutralization of Special Elements used in a Command, MITRE, liste 4.20 : définition, note de mappage « Allowed-with-Review », entrées filles.
CWE-1427: Improper Neutralization of Input Used for LLM Prompting, MITRE : l’injection de prompt comme fille de CWE-77.
2025 CWE Top 25, MITRE : rang 23, en recul de dix places.

🐝 Ce qui arrive si on s’en passe

Une équipe qui n’identifie pas l’interpréteur en aval applique au hasard des parades conçues pour un autre : elle échappe des métacaractères d’interpréteur de commandes dans une chaîne destinée à un moteur de règles, ce qui ne protège de rien tout en donnant le sentiment d’avoir traité le sujet. Le défaut reste, et il est désormais invisible, car le code contient une fonction qui s’appelle « assainir ». Le coût le plus élevé se paie aujourd’hui sur le dernier interpréteur de la famille : une organisation qui branche un modèle de langage sur ses outils internes sans comprendre qu’elle vient d’ajouter un interpréteur non déterministe à son architecture laisse un contenu extérieur (une page lue, un courriel traité, un document indexé) dicter des actions exécutées avec les droits de l’application. Il n’y a alors ni requête malformée dans les journaux, ni signature à détecter : seulement une suite d’actions légitimes, décidées par quelqu’un d’autre.

🦫 Explication de la marmotte 🍫

Un programme parle souvent à d’autres programmes en leur envoyant des commandes écrites. Ces commandes obéissent à une grammaire : certains signes ne sont pas du texte mais des instructions de structure.

Le défaut consiste à fabriquer une telle commande en y recopiant ce que l’utilisateur a fourni. Si l’utilisateur écrit, au lieu d’un simple mot, du texte contenant la grammaire du destinataire, il modifie la commande elle-même. Le destinataire exécute : il n’a aucun moyen de savoir quelle partie venait du programmeur et quelle partie venait d’un inconnu.

Le catalogue CWE distingue deux cas. Quand le destinataire est le système d’exploitation, le défaut porte le numéro CWE-78. Quand le destinataire est un autre interpréteur (un moteur de règles, un langage de formules, un système de modèles de documents), c’est CWE-77, celui décrit ici. L’organisme qui tient le catalogue note d’ailleurs que les deux sont fréquemment confondus, et le classement de 2025 reflète surtout un travail de reclassement : les failles n’ont pas diminué, elles ont été mieux rangées.

La fille la plus récente de cette catégorie mérite l’attention. Elle concerne les modèles de langage : quand un programme construit une consigne pour une intelligence artificielle en y mélangeant du texte venu de l’extérieur (un courriel, une page web, un document), le modèle ne distingue pas la consigne du programmeur du contenu qu’il lit. Il peut donc suivre des instructions glissées dans le document.

Et c’est là que la comparaison s’arrête. Dans tous les autres cas, on sait séparer proprement les instructions des données. Avec un modèle de langage, cette séparation n’est pas garantie. La seule protection solide consiste donc à restreindre ce que le programme fera de la réponse du modèle : vérifier chaque action avant de l’exécuter, et demander l’accord d’une personne pour tout ce qui est irréversible.

Pages voisines

La citent

CWE-77 : injection de commande, la classe au-dessus de l'interpréteur système

Elle cite

: les deux pages se citent l’une l’autre.