Qu'est-ce que l'injection de commandes système ? Exploitation, impact et défense

Qu'est-ce que l'injection de commandes système (OS Command Injection) ?

L'injection de commandes système est une vulnérabilité qui permet à des attaquants d'exécuter des commandes arbitraires du système d'exploitation sur un serveur via une application vulnérable. Classée CWE-78 par MITRE, elle survient lorsqu'une application construit des commandes système à partir d'une entrée externe sans neutraliser correctement les caractères spéciaux susceptibles de modifier la commande prévue. Le résultat est un accès direct et non autorisé au système d'exploitation sous-jacent.

Cette classe de vulnérabilité a été liée à des cyberattaques majeures, de l'exploitation massive de Shellshock en 2014 au ciblage continu des équipements réseau documenté dans un avis de la CISA. CWE-78 figure parmi les 25 principales faiblesses de MITRE, aux côtés de l'écriture hors limites, cross-site scripting et SQL injection.

Dans l'OWASP Top 10, la catégorie plus large Injection couvre à la fois CWE-77 et CWE-78. Comprendre le fonctionnement de la vulnérabilité au niveau du shell est la première étape pour l'arrêter.

Comment fonctionne l'injection de commandes système ?

L'injection de commandes système exploite une faille fondamentale : une application transmet une entrée contrôlée par l'utilisateur directement à une commande shell du système d'exploitation sans séparer les données des instructions de contrôle.

MITRE identifie deux sous-types d'injection de commandes système.

Sous-type 1 : Direct (injection par séparateur de commande)

L'application vise à exécuter un seul programme fixe, en utilisant l'entrée externe uniquement comme arguments. Les attaquants injectent des séparateurs de commande (;, |, &&, || ou retours à la ligne) pour ajouter des commandes supplémentaires.

Considérons une application web effectuant des recherches DNS :

Un attaquant fournit example.com; cat /etc/passwd comme paramètre de domaine. Le shell exécute à la fois nslookup example.com et cat /etc/passwd, renvoyant le fichier des mots de passe du serveur.

Sous-type 2 : Indirect (contrôle total de la commande)

L'application accepte une entrée qui détermine entièrement quel programme exécuter. L'attaquant contrôle la commande complète, pas seulement ses arguments :

Si un attaquant contrôle la propriété SCRIPTNAME, il peut la faire pointer vers n'importe quel exécutable du système.

Le déroulement de l'attaque

Une attaque typique d'injection de commandes système suit cette séquence :

L'attaquant identifie un champ de saisie, tel qu'un paramètre de formulaire, un en-tête HTTP, un cookie ou une chaîne de requête URL, qui alimente une commande côté serveur.
L'attaquant injecte des métacaractères shell combinés à une commande malveillante dans cette entrée.
L'application transmet l'entrée non filtrée au shell du système d'exploitation.
Le shell interprète les métacaractères et exécute la commande injectée avec les mêmes privilèges que le processus applicatif. Si l'application s'exécute en tant que root, l'attaquant obtient ces mêmes privilèges.

Chacune de ces étapes dépend de l'interprétation par le shell de certains caractères comme instructions de contrôle. Les opérateurs permettant cela varient selon la plateforme.

Opérateurs et métacaractères d'injection courants

L'injection de commandes système repose sur des métacaractères shell qui modifient la façon dont le système d'exploitation interprète une chaîne de commande. Les opérateurs disponibles pour un attaquant dépendent de la plateforme cible.

Séparateurs de commande et exécution en ligne

Opérateur	Fonction	Plateforme
;	Exécute les commandes séquentiellement	Unix
&	Exécute la seconde commande en arrière-plan	Unix et Windows
&&	Exécute la seconde commande uniquement si la première réussit	Unix et Windows
\|\|	Exécute la seconde commande uniquement si la première échoue	Unix et Windows
\|	Redirige la sortie de la première commande vers la seconde	Unix et Windows
` (backticks)	Exécution en ligne ; la sortie remplace l'expression	Unix
$()	Exécution en ligne ; équivalent fonctionnel des backticks	Unix
0x0a (retour à la ligne)	Démarre une nouvelle commande sur certains shells	Unix

Lorsque l'entrée utilisateur se retrouve dans une chaîne entre guillemets dans la commande d'origine, l'attaquant doit d'abord fermer le guillemet (" ou ') avant que tout séparateur ne prenne effet. Des techniques d'encodage telles que l'encodage URL, le double encodage et la normalisation Unicode peuvent également contourner les filtres qui vérifient ces caractères sous leur forme littérale. Ces opérateurs atteignent le shell en raison de schémas de codage spécifiques qui ne séparent pas les données utilisateur de la syntaxe de commande.

Causes de l'injection de commandes système

L'injection de commandes système provient de pratiques de codage qui permettent à l'entrée utilisateur d'atteindre un shell système sans contrôles adéquats. Cinq causes principales expliquent la majorité des vulnérabilités.

Validation d'entrée insuffisante

C'est la cause la plus directe. Selon le guide OWASP, les attaques d'injection de commandes deviennent possibles lorsqu'une application transmet des données utilisateur non sûres, telles que des formulaires, cookies et en-têtes HTTP, à un shell système sans les filtrer. Si vous faites confiance aux utilisateurs pour fournir des valeurs attendues, vous pouvez omettre la validation.

Utilisation de l'exécution shell au lieu des API natives du langage

Appeler system(), exec(), shell_exec() ou os.system() invoque le shell du système d'exploitation comme intermédiaire. Chaque appel au shell crée une surface d'injection. La cheat sheet OWASP identifie les API dangereuses dans les principaux langages :

Langage	API dangereuses
Java	Runtime.exec()
C / C++	system(), exec(), ShellExecute()
Python	exec(), eval(), os.system(), os.popen(), subprocess.Popen(), subprocess.call()
PHP	system(), shell_exec(), exec(), proc_open(), eval(), passthru()
Node.js	child_process.exec(), execSync(), spawn()

Dépendance au filtrage par liste de blocage

Vous pouvez tenter de bloquer certains caractères dangereux au lieu de définir ce qui est autorisé. Cette approche, classée comme CWE-184 (liste de blocage incomplète), échoue systématiquement. OWASP documente explicitement que escapeshellcmd() de PHP empêche l'exécution de commandes supplémentaires mais autorise toujours l'injection d'arguments. Les attaquants peuvent injecter des options comme --output-document= pour écrire des fichiers sans utiliser de séparateurs de commande.

Manipulation des variables d'environnement

Lorsque les applications ne spécifient pas de chemins absolus pour les exécutables et ne nettoient pas les variables d'environnement, les attaquants peuvent rediriger $PATH vers des binaires malveillants. Si l'application s'exécute avec les privilèges root (setuid), le binaire de l'attaquant s'exécute avec ces droits.

Violation du principe du moindre privilège

Les applications s'exécutant avec des privilèges élevés amplifient chaque faille d'injection. Une injection de commande contre une application s'exécutant sous www-data limite l'attaquant aux droits de cet utilisateur. La même injection sur un processus root accorde un contrôle total du système. Si l'une de ces causes n'est pas traitée, l'impact s'étend bien au-delà de l'application vulnérable elle-même.

Impact et risque de l'injection de commandes système

L'injection de commandes système obtient systématiquement les scores les plus élevés dans les systèmes de classification des vulnérabilités. Le OWASP Top 10:2021 identifie l'injection comme une catégorie de risque majeure et persistante. L'impact fonctionnel est direct : un attaquant obtient la capacité d'exécuter des commandes arbitraires sur votre serveur avec les mêmes privilèges que le processus applicatif compromis.

Gravité par catégorie d'impact

Impact	Preuve
Exécution de code à distance	CVE-2024-3400
Compromission complète du système	Rapport SANS : "compromission complète du système, exfiltration de données ou infiltration du réseau"
Mouvement latéral	Avis CISA : injection de commandes système combinée à la traversée de répertoires permettant une intrusion en plusieurs étapes
Recrutement de botnet	Variante Mirai
Livraison de ransomware	Avis CISA; Avis CISA

Les scores CVSS ne racontent pas toute l'histoire

CVE-2024-20399 (Cisco NX-OS) affiche un score CVSS relativement modeste et nécessite un accès local et des privilèges administratifs. Pourtant, la CISA l'a ajouté au catalogue des vulnérabilités exploitées après avoir confirmé son exploitation par la campagne Velvet Ant liée à la Chine.

Ce cas illustre que les scores CVSS seuls ne reflètent pas le risque opérationnel. L'appartenance au catalogue KEV, l'exploitation par des États-nations et la position du dispositif sur le réseau sont des facteurs de risque indépendants qui peuvent largement dépasser un score de base. Comprendre les techniques spécifiques utilisées par les attaquants aide à expliquer pourquoi l'exploitation confirmée est si courante.

Comment les attaquants exploitent l'injection de commandes système

Les attaquants utilisent une progression de techniques pour trouver, confirmer et exploiter l'injection de commandes système, en commençant par la découverte et en escaladant via l'injection aveugle et la chaîne de vulnérabilités.

Découverte et énumération

Les attaquants identifient les champs de saisie qui interagissent avec des commandes système côté serveur, testant tous les paramètres, en-têtes HTTP (User-Agent, Referer), cookies, chaînes de requête URL et entrées de données structurées (JSON, XML, SOAP).

Injection directe avec sortie visible

Un attaquant injecte un séparateur de commande suivi d'une commande de sortie connue :

Si la réponse contient le nom d'utilisateur du processus en cours d'exécution, l'injection est confirmée et l'attaquant peut passer à des commandes plus dommageables.

Injection aveugle par délais temporels

Lorsque la sortie de la commande n'apparaît pas dans la réponse HTTP, les attaquants injectent des commandes de délai et mesurent la latence de la réponse. Injecter & sleep 10 & sur une cible Linux produit un délai mesurable si la commande s'exécute.

Exfiltration hors bande (OAST)

Les attaquants injectent des commandes qui déclenchent des requêtes DNS vers une infrastructure qu'ils contrôlent :

Une requête DNS arrivant sur le serveur de l'attaquant confirme l'exécution de code, même en l'absence de sortie ou de différence de temps observable. PortSwigger OAST note que Burp Collaborator a permis de détecter des vulnérabilités d'injection de commandes système aveugles auparavant indétectables par d'autres moyens.

Chaînage avec contournement d'authentification

CVE-2024-21887 (Ivanti Connect Secure) nécessite un accès administrateur authentifié, mais les attaquants l'ont couplé à CVE-2023-46805 (contournement d'authentification) pour éliminer totalement cette exigence. Selon un avis CISA, des acteurs étatiques chinois ont systématiquement utilisé ce schéma de chaînage sur Ivanti, Cisco et d'autres équipements réseau.

Contournement par injection d'arguments

Lorsque les défenseurs filtrent les séparateurs de commande (;, |, &&), les attaquants se tournent vers l'injection d'arguments (CWE-88). En injectant des options précédées de - ou --, ils manipulent le comportement d'un programme déjà invoqué sans introduire de nouvelles commandes. OWASP documente que escapeshellcmd() de PHP permet cette attaque même lorsque les séparateurs de commande sont bloqués. L'étendue de ces techniques signifie que l'impact ne se limite pas à un seul type d'application ou secteur.

Qui est concerné par l'injection de commandes système ?

L'injection de commandes système affecte tout système où le code applicatif transmet une entrée utilisateur à un shell système. Certains types d'applications et secteurs présentent un risque disproportionné selon les données d'exploitation confirmée.

Types d'applications les plus vulnérables

Équipements réseau et dispositifs SSL-VPN : Cette catégorie concentre le plus grand nombre d'entrées CWE-78 exploitées confirmées dans le catalogue KEV de la CISA. CVE-2023-44221 (SonicWall SMA100), CVE-2024-8190 (Ivanti Cloud Services Appliance), CVE-2024-40891 (Zyxel CPE) et CVE-2023-28771 (Zyxel Firewall/VPN) impliquent tous des interfaces de gestion transmettant directement des entrées à l'exécution de commandes système.
IoT et firmwares embarqués : Les appareils NAS QNAP (CVE-2023-47218), routeurs TP-Link (CVE-2023-1389) et routeurs Wavlink présentent tous des vulnérabilités CWE-78 confirmées. La variante Mirai a systématiquement exploité des CVE d'injection de commandes système sur plusieurs plateformes de routeurs et firmwares IoT pour le recrutement de botnets.
Applications web avec appels système côté serveur : Le scénario canonique OWASP Top 10 décrit une application Java construisant une commande système via Runtime.getRuntime().exec() avec concaténation de chaînes.
Interfaces de gestion d'entreprise : Un avis CISA documente l'exploitation d'interfaces de gestion Ivanti Cloud Service Application via une chaîne d'injection de commandes.

Secteurs les plus à risque

Infrastructures critiques et télécommunications : Un avis CISA documente l'exploitation par des acteurs étatiques chinois de l'injection de commandes dans des équipements réseau ciblant les infrastructures télécoms et routeurs.
Gouvernement fédéral : Les entrées KEV de la CISA "présentent des risques importants pour l'entreprise fédérale". Les agences fédérales font face à des délais KEV pour les CVE d'injection de commandes listées.

Les données d'exploitation dans ces catégories montrent comment l'injection de commandes système passe d'une faille de code à un dommage à l'échelle organisationnelle.

Exemples concrets d'injection de commandes système

Des incidents confirmés d'injection de commandes système vont de l'exploitation massive de logiciels open source à des campagnes ciblées d'États-nations contre des infrastructures réseau.

Shellshock (CVE-2014-6271), 2014

GNU Bash jusqu'à la version 4.3 traitait les chaînes après les définitions de fonctions dans les variables d'environnement, permettant à des valeurs forgées d'injecter des commandes shell. Cette vulnérabilité était exploitable via des scripts CGI, des clients DHCP et des configurations SSH ForceCommand, démontrant la surface d'attaque à l'échelle d'Internet d'une seule faille d'injection de commandes système.

Piratage d'Equifax (CVE-2017-5638), 2017

Apache Struts 2 permettait aux attaquants d'injecter des expressions OGNL via les en-têtes Content-Type, permettant l'exécution de code arbitraire. Selon le rapport du Congrès, Apache a publié un correctif le 7 mars 2017. Trois jours plus tard, le 10 mars, les attaquants ont exploité la vulnérabilité sur le réseau d'Equifax. La violation a conduit à un règlement de 700 millions de dollars et à la démission de dirigeants.

Log4Shell (CVE-2021-44228), 2021

La fonctionnalité JNDI de recherche de messages d'Apache Log4j2 permettait une exécution de code à distance non authentifiée via des messages de log forgés, CVSS 10.0. Selon un avis CISA, des acteurs APT ont exploité Log4Shell sur des serveurs VMware Horizon non corrigés, réalisé des mouvements latéraux et exfiltré des données sensibles. Des affiliés LockBit et des groupes nord-coréens ont également exploité cette vulnérabilité.

Velvet Ant / CVE-2024-20399, 2024

Le rapport Sygnia décrit un groupe d'espionnage lié à la Chine exploitant une vulnérabilité d'injection de commandes CLI sur Cisco NX-OS. Malgré un score CVSS relativement faible, le groupe a exécuté du code malveillant sur le système Linux sous-jacent des commutateurs Nexus. La CISA l'a ajouté au catalogue KEV, soulignant que le risque opérationnel dépasse souvent ce que reflète le CVSS.

Exploitation de pare-feu Zyxel (CVE-2023-28771), 2023

Une gestion incorrecte des messages d'erreur dans le firmware des pare-feu Zyxel permettait une exécution de commandes système à distance non authentifiée, CVSS 9.8. Cybersecurity Dive a rapporté un ciblage actif en une seule journée sans activité préalable.

Ces incidents s'inscrivent dans un schéma plus large remontant aux débuts des applications web.

Chronologie et historique de l'injection de commandes système

1988 à 1998 : L'ère CGI. Les premiers serveurs web invoquaient des scripts shell avec des entrées utilisateur non filtrées, créant les premières surfaces d'attaque d'injection de commandes système. Le jeu de données DARPA Intrusion Detection Evaluation sur MIT Lincoln Laboratory a catalogué les attaques basées sur CGI et l'exploitation de sendmail de cette période.
1999 : Classification formelle. CVE-1999-0067 a documenté l'une des premières entrées formelles d'injection de commandes : un programme CGI ne neutralisant pas le métacaractère pipe (|) lors de l'appel d'un programme d'annuaire téléphonique. Le CWE-78 de MITRE a codifié la classe de vulnérabilité.
2014 : Shellshock. CVE-2014-6271 est devenue la première vulnérabilité d'injection de commandes système à être exploitée massivement à l'échelle d'Internet.
2017 : Conséquences pour l'entreprise. La violation Equifax via CVE-2017-5638 a démontré que les primitives d'exécution de commandes intégrées dans les frameworks applicatifs ont des conséquences équivalentes à une injection de commandes système directe à l'échelle de l'entreprise.
2021 : Consolidation de la catégorie Injection. L'OWASP Top 10:2021 a regroupé tous les types d'injection sous la catégorie A03 Injection. Log4Shell (CVE-2021-44228) a étendu le schéma à une bibliothèque de journalisation omniprésente.
2023 à 2026 : Ciblage des équipements réseau. La surface d'attaque s'est déplacée de façon décisive vers les équipements de périmètre réseau. Selon un avis CISA, des acteurs étatiques chinois ont systématiquement exploité l'injection de commandes dans des équipements réseau de 2021 à 2025. L'OWASP Top 10:2025 a explicitement ajouté CWE-88 (injection d'arguments) comme faiblesse cartographiée.

L'exploitation étant toujours en cours, l'identification précoce reste une priorité tout au long du cycle de vie applicatif.

Comment détecter l'injection de commandes système

La détection de l'injection de commandes système nécessite une approche multicouche combinant tests pré-déploiement et visibilité à l'exécution.

Analyse statique de sécurité applicative (SAST)

Selon l' OWASP Top 10, la revue de code source est la meilleure méthode pour détecter les vulnérabilités d'injection. Les outils SAST signalent les appels à system(), exec(), popen(), shell_exec() et autres API dangereuses recevant une entrée contrôlée par l'utilisateur. Les schémas clés à signaler incluent la concaténation de chaînes alimentant des fonctions d'exécution de commandes système et l'utilisation de escapeshellcmd() en PHP au lieu du plus sûr escapeshellarg().

Vous devez exécuter SAST dans votre pipeline CI/CD pour détecter les failles d'injection avant le déploiement. Sa principale limite est qu'il ne peut pas détecter les vulnérabilités qui ne se manifestent qu'à l'exécution.

Analyse dynamique de sécurité applicative (DAST)

DAST valide ce qui est réellement exploitable en testant l'application en cours d'exécution. Web Security Academy documente trois techniques DAST :

Injection directe avec sortie : Injecter & echo uniquestring & et vérifier si la chaîne apparaît dans la réponse.
Injection aveugle basée sur le temps : Injecter & sleep 10 & et mesurer le délai de réponse.
Injection hors bande (OAST) : Injecter des commandes de rappel DNS et surveiller les requêtes externes vers un serveur contrôlé. C'est la technique la plus fiable pour l'injection aveugle.

Visibilité comportementale au niveau des processus

Au niveau de l'hôte, NIST SP 800-53 (Surveillance des systèmes d'information) établit le cadre pour l'identification des anomalies comportementales. Votre SOC doit rechercher ces indicateurs spécifiques :

Processus de serveur web (apache, nginx, tomcat) lançant des processus shell (bash, sh, cmd.exe, powershell)
Appels inattendus à execve() ou system() provenant de contextes de processus applicatifs web
Connexions réseau sortantes initiées par des processus applicatifs vers des IP externes

Règles de pare-feu applicatif web (WAF)

L'OWASP ModSecurity Core Rule Set signale les métacaractères shell (;, |, &, backticks, $()) et les commandes système courantes (whoami, cat /etc/passwd, nslookup) dans les entrées HTTP. Les règles WAF peuvent être contournées via l'encodage et la variation de casse ; elles doivent donc être considérées comme une source de signal, non comme un contrôle complet.

Comparaison des méthodes

Méthode	Période	Détecte l'injection aveugle	Limite principale
SAST	Pré-déploiement	N/A (statique)	Ne détecte pas les problèmes uniquement à l'exécution
DAST	Pré/post-déploiement	Oui (via OAST)	Peut manquer des flux complexes
Visibilité comportementale	Production	Oui	Nécessite un ajustement de la base de référence
WAF	Production	Partiellement	Contournable, ne corrige pas la cause racine

Détecter les vulnérabilités ne suffit pas. La prévention exige d'éliminer la cause racine dans votre code et votre architecture.

Comment prévenir l'injection de commandes système

La prévention vise à éliminer la cause racine : l'appel direct au shell système avec une entrée contrôlée par l'utilisateur. Lorsque les appels shell ne peuvent être supprimés, des contrôles en couches réduisent la surface d'attaque.

Défense principale : éviter totalement les commandes système

Selon PortSwigger, la meilleure prévention consiste à ne jamais appeler de commandes système depuis le code applicatif. Dans presque tous les cas, vous pouvez implémenter la fonctionnalité requise via des API natives plus sûres. Pour envoyer un e-mail, utilisez une bibliothèque SMTP. Pour la résolution DNS, utilisez une bibliothèque DNS. Éliminez l'intermédiaire shell.

Utiliser des API de commandes paramétrées

Lorsque l'exécution de commandes système est inévitable, utilisez des mécanismes structurés qui imposent la séparation entre données et commande. En Python, cela signifie utiliser la forme liste de subprocess.run() :

La forme basée sur une liste empêche le shell d'interpréter les métacaractères dans tout argument.

Validation d'entrée par liste d'autorisation

La cheat sheet OWASP recommande la validation basée sur une liste d'autorisation comme seconde couche de défense. Définissez les caractères autorisés et la longueur maximale de chaîne via des expressions régulières strictes. OWASP fournit l'exemple ^[a-z0-9]{3,10}$, excluant tous les métacaractères et espaces.

PortSwigger avertit explicitement : n'essayez jamais de filtrer l'entrée en échappant les métacaractères shell. Cette approche est sujette à erreur et vulnérable au contournement par des attaquants expérimentés. La liste d'autorisation est toujours préférable.

Appliquer le principe du moindre privilège (NIST AC-6)

NIST SP 800-53 impose l'application du principe du moindre privilège. Pour la défense contre l'injection de commandes :

Exécutez les processus applicatifs web sous des comptes de service dédiés et non privilégiés
Limitez les droits des comptes de service aux seuls chemins nécessaires du système de fichiers
Refusez l'accès shell (/bin/sh, /bin/bash) aux comptes de service applicatifs web
Appliquez des profils seccomp sous Linux pour restreindre les appels système disponibles

Mettre en œuvre l'isolation et la conteneurisation

L'isolation par conteneur avec systèmes de fichiers racine en lecture seule, espaces de noms et cgroups Linux, et profils de contrôle d'accès obligatoires (AppArmor ou SELinux) réduisent tous le rayon d'impact en cas d'injection. Ces contrôles sont conformes aux principes de moindre fonctionnalité NIST CM-7.

Contrôles spécifiques à PHP

Si vous travaillez en PHP et devez invoquer des commandes shell, utilisez escapeshellarg() plutôt que escapeshellcmd(), car il limite l'entrée à un seul paramètre et empêche l'injection d'arguments.

Ces contrôles de codage et d'architecture constituent la base, mais les outils offrent la visibilité nécessaire pour les appliquer à grande échelle.

Outils de détection et de prévention de l'injection de commandes système

Une défense efficace nécessite des outils couvrant les tests de sécurité applicative, la protection à l'exécution et la visibilité sur les endpoints. Une alerte conjointe CISA et FBI ciblant l'injection de commandes système recommande spécifiquement l'utilisation de fonctions de bibliothèque intégrées séparant les commandes de leurs arguments, la paramétrisation des entrées et la validation de toutes les données utilisateur.

Outils de test de sécurité applicative

Les outils SAST analysent le code source à la recherche d'appels d'API dangereux recevant une entrée utilisateur. Vous pouvez les intégrer à votre pipeline CI/CD pour détecter les failles d'injection avant le déploiement.
Les outils DAST tels que Burp Suite testent les applications en cours d'exécution pour détecter les points d'injection exploitables. Les capacités OAST de Burp Suite sont particulièrement efficaces pour détecter l'injection de commandes aveugle sans sortie visible.

Protection à l'exécution et au niveau réseau

Solutions WAF utilisant l'OWASP ModSecurity Core Rule Set assurent un filtrage réseau des métacaractères shell et des charges d'injection courantes. Elles constituent une défense en profondeur mais ne doivent pas remplacer la correction de la cause racine.
Les solutions RASP instrumentent les applications à l'exécution et peuvent bloquer les tentatives d'injection avec le contexte applicatif complet, servant de contrôle compensatoire pour les applications héritées difficiles à corriger.

Visibilité endpoint et comportementale

Les plateformes de sécurité endpoint surveillant la création de processus, les relations parent-enfant et les arguments en ligne de commande sont essentielles pour détecter l'activité post-exploitation. Lorsqu'un processus serveur web lance un shell inattendu, l'analyse comportementale au niveau du noyau devient votre dernière ligne de défense.

Une cybersécurité alimentée par l'IA

Améliorez votre posture de sécurité grâce à la détection en temps réel, à une réponse à la vitesse de la machine et à une visibilité totale de l'ensemble de votre environnement numérique.

Obtenir une démonstration

Vulnérabilités associées

L'injection de commandes système fait partie d'une famille de vulnérabilités d'injection partageant une cause racine commune : l'absence de séparation entre les données utilisateur et les instructions exécutables. Plusieurs classes de vulnérabilités associées peuvent se chaîner ou se recouper avec CWE-78.

Injection SQL (CWE-89) : Cible les moteurs de base de données SQL plutôt que le shell système. L'injection SQL peut se chaîner à l'injection de commandes système via des fonctionnalités comme xp_cmdshell.
Injection de code (CWE-94) : Cible le runtime du langage applicatif (PHP eval(), Python exec()). L'injection de code permet à l'attaquant d'ajouter son propre code exécuté par l'application, et peut escalader vers l'injection de commandes système si le code injecté appelle system() ou exec().
Injection d'arguments (CWE-88) : Variante enfant de CWE-78. Plutôt que d'injecter de nouvelles commandes via des séparateurs, les attaquants manipulent les arguments d'un programme déjà invoqué à l'aide de caractères d'option (-, --). Cette attaque réussit même si le filtrage des séparateurs de commande est en place.
Injection de modèles côté serveur (CWE-1336) : Cible les moteurs de templates (Jinja2, FreeMarker). L'injection SSTI escalade fréquemment vers l'injection de commandes système car les moteurs de templates ont souvent accès au runtime du langage sous-jacent.
Injection de langage d'expression (CWE-917) : Cible les analyseurs de langage d'expression dans les frameworks web (OGNL, Spring SpEL). Log4Shell (CVE-2021-44228) en est l'exemple le plus marquant, se chaînant fréquemment à l'exécution de commandes système.

Vulnérabilité	CWE	Interpréteur ciblé	Chemin direct vers l'exécution OS
Injection de commandes système	CWE-78	Shell système	Direct
Injection SQL	CWE-89	Moteur SQL	Indirect (via xp_cmdshell)
Injection de code	CWE-94	Runtime applicatif	Indirect (via appels système)
Injection d'arguments	CWE-88	Analyseur d'arguments shell	Direct (manipule la commande invoquée)
SSTI	CWE-1336	Moteur de templates	Escalade fréquemment vers commandes système
Injection EL	CWE-917	Analyseur de langage d'expression	Escalade fréquemment vers commandes systèmes

Le tableau ci-dessus montre que plusieurs classes de vulnérabilités offrent un chemin direct ou indirect vers l'exécution au niveau du système d'exploitation, rendant essentielle une défense en profondeur sur tous les types d'injection.

CVEs associés

ID CVE	Description	Gravité	Produit affecté	Année
CVE-2026-33718	Injection de commande dans l'API git diff contournant les contrôles d'exécution d'agent	Critique	OpenHands AI Platform	2026
CVE-2026-25857	Injection de commandes système dans la fonctionnalité de diagnostic WAN via le paramètre curl	Critique	Tenda G300-F Router	2026
CVE-2026-0631	Injection de commandes système dans les modules VPN ; attaquant authentifié adjacent	Élevée	TP-Link Archer BE230	2026
CVE-2025-64127	Injection de commandes système non authentifiée dans des dispositifs de communication ICS	Critique	Zenitel Devices	2025
CVE-2025-34041	Injection de commandes système non authentifiée dans la plateforme de gestion EDR ; exploitation active	Critique	Sangfor EDR	2025
CVE-2025-11730	Injection de commande post-authentification dans la configuration CLI DDNS	Élevée	Zyxel ATP/USG FLEX Firewalls	2025
CVE-2025-65791	Injection de commande via entrée non filtrée transmise à exec() dans image.php	Critique	ZoneMinder v1.36.34	2025
CVE-2025-54123	RCE non authentifiée via injection de commande dans l'API middleware	Critique	Hoverfly API Simulator	2025
CVE-2024-20399	Injection de commande CLI sur commutateurs Nexus ; exploitée par la campagne Velvet Ant	Moyenne	Cisco NX-OS	2024
CVE-2024-10443	Injection de commandes système non authentifiée dans le composant Task Manager	Critique	Synology BeePhotos/Photos	2024
CVE-2024-29972	Injection de commande non authentifiée dans l'endpoint remote_help-cgi	Critique	Zyxel NAS326/NAS542	2024
CVE-2024-40890	Injection de commande post-authentification via HTTP POST dans un programme CGI ; CISA KEV	Élevée	Zyxel VMG1312-B10A	2024
CVE-2024-12828	Injection de commande via requête CGI permettant l'exécution de code au niveau root	Critique	Webmin	2024
CVE-2023-20273	Injection de commande au niveau root via l'interface web ; exploitation active ; CISA KEV	Critique	Cisco IOS XE	2023
CVE-2023-2868	Injection de commande via noms de fichiers .tar malveillants ; exploitation active ; CISA KEV	Critique	Barracuda ESG	2023
CVE-2023-27992	Injection de commandes système pré-authentification via requêtes HTTP ; CISA KEV	Critique	Zyxel NAS326/540/542	2023
CVE-2023-35138	Injection de commande non authentifiée dans la fonction show_zysync_server_contents	Critique	Zyxel NAS326/NAS542	2023
CVE-2023-51385	Injection de commandes système via métacaractères shell dans les noms d'utilisateur ou d'hôte	Moyenne	OpenBSD OpenSSH	2023
CVE-2022-44877	Injection de métacaractères shell non authentifiée dans l'interface de connexion ; CISA KEV	Critique	Control Web Panel 7	2022
CVE-2022-2068	Injection de commande via noms de fichiers de certificats malveillants dans le script c_rehash	Critique	OpenSSL	2022
CVE-2021-4039	Injection de commandes système non authentifiée via l'interface de gestion web	Critique	Zyxel NWA1100-NH	2021
CVE-2020-8515	Injection de commande pré-authentification dans le firmware du routeur ; CISA KEV	Critique	DrayTek Vigor Routers	2020
CVE-2020-9054	Injection de commande pré-authentification via weblogin.cgi ; élévation root ; CISA KEV	Critique	Zyxel NAS326	2020
CVE-2020-10987	Injection de commande via le paramètre deviceName dans goform/setUsbUnload ; CISA KEV	Critique	Tenda AC15 Router	2020

Conclusion

L'injection de commandes système donne aux attaquants une exécution directe au niveau du système d'exploitation via des applications transmettant des entrées non sûres à des interpréteurs shell. Vous réduisez l'exposition en supprimant les appels de commandes système lorsque possible, en utilisant des API paramétrées si nécessaire et en appliquant une validation par liste d'autorisation.

Si la prévention échoue, la visibilité comportementale au niveau du endpoint vous aide à détecter rapidement le lancement de shell, les connexions sortantes et d'autres signes d'exploitation.

FAQ

L'injection de commandes système (CWE-78) est une vulnérabilité où une application construit des commandes du système d'exploitation à partir d'une entrée externe non filtrée. Les attaquants injectent des métacaractères de shell (;, |, &&) pour ajouter des commandes malveillantes que le shell du système exécute avec les privilèges de l'application.

La cause principale est l'absence de séparation entre les données utilisateur et la syntaxe des commandes avant de transmettre l'entrée à un interpréteur de shell.

Oui. L'injection de commandes système est classée dans la catégorie Injection dans l'OWASP Top 10:2021 et l'OWASP Top 10:2025. Les CWE-77 et CWE-78 sont explicitement inclus.

L'édition 2025 a également ajouté CWE-88 (Argument Injection) comme faiblesse cartographiée.

Oui. La plupart des vulnérabilités CWE-78 confirmées dans le catalogue CISA KEV ne nécessitent aucune authentification et sont exploitables à distance. CVE-2014-6271 (Shellshock), CVE-2023-28771 (Zyxel), et CVE-2024-3400 permettent toutes une exploitation à distance sans authentification.

Les équipements réseau, y compris les pare-feux, les concentrateurs VPN et les commutateurs d'entreprise, produisent la plus forte concentration d'entrées CWE-78 confirmées comme exploitées. Les micrologiciels IoT et embarqués, y compris les dispositifs NAS et les routeurs, sont systématiquement ciblés pour le recrutement de botnets.

Les applications web qui invoquent des commandes système côté serveur et les interfaces de gestion d'entreprise présentent également un risque accru.

Les attaquants testent les champs de saisie, les en-têtes HTTP, les cookies et les paramètres d'URL en injectant des métacaractères de shell suivis de commandes de diagnostic. Pour l'injection aveugle, ils utilisent des délais (sleep 10) ou des callbacks DNS vers des serveurs contrôlés par l'attaquant.

Les scanners et outils de fuzzing testent systématiquement tous les vecteurs d'entrée.

Les indicateurs clés incluent des processus de serveur web (apache, nginx, tomcat) lançant des processus shell inattendus (bash, sh, cmd.exe). D'autres signes sont des connexions réseau sortantes depuis des processus applicatifs vers des IP inconnues et des appels inhabituels à execve() ou system() depuis le contexte du processus de l'application web.

L'injection de commandes système est une classe de vulnérabilité de gravité élevée car elle donne aux attaquants un accès direct au niveau du système d'exploitation, ce qui signifie qu'ils peuvent exécuter toute commande prise en charge par l'OS hôte.

CWE-78 figure parmi les principales catégories de faiblesses logicielles MITRE, et les CVE confirmés affichent régulièrement des scores CVSS de 9,0 ou plus.

Oui. Le rapport du SANS sur la CVE-2024-40891 décrit explicitement une "compromission complète du système, exfiltration de données ou infiltration du réseau." Lorsque l'application compromise s'exécute avec des privilèges élevés, les attaquants obtiennent un accès équivalent au niveau du système d'exploitation.

Les conséquences confirmées incluent le déploiement de rançongiciels, les mouvements latéraux et l'installation persistante de portes dérobées.

Les outils SAST signalent de manière fiable les appels API dangereux dans le code source mais manquent les vulnérabilités présentes uniquement à l'exécution. Les outils DAST identifient les points d'injection exploitables, notamment en utilisant des techniques OAST pour l'injection aveugle.

Les règles WAF détectent les schémas connus mais peuvent être contournées par encodage. La visibilité comportementale au niveau des processus offre l'identification à l'exécution la plus fiable. Aucun outil unique ne détecte toutes les variantes, une couverture en couches est donc nécessaire.

Les infrastructures critiques et les télécommunications présentent le risque confirmé le plus élevé. Les avis CISA documentent l'exploitation par des acteurs étatiques chinois ciblant les télécoms et l'infrastructure des routeurs.

Les agences gouvernementales fédérales sont soumises à des délais de remédiation KEV obligatoires. Tout secteur utilisant des équipements réseau exposés à Internet ou des firmwares embarqués est une cible potentielle.