Exploiter les serveurs MCP vulnérables aux injections de commandes

Les serveurs MCP connaissent un succès fulgurant. Permettre aux LLM d’étendre leurs capacités grâce aux serveurs MCP est un workflow de plus en plus adopté, mais à quel prix ? Que se passe-t-il lorsque vous ajoutez des serveurs MCP à vos workflows d’IA agentique et de LLM, sujets à diverses vulnérabilités de sécurité ?

Les serveurs MCP peuvent être utilisés avec des applications d’IA courantes, comme Claude Desktop et Raycast. Toutefois, ils peuvent représenter une menace plus importante lorsqu’ils sont associés au codage assisté par l’IA et aux workflows de développement logiciel autonome.

Pourquoi les serveurs MCP vulnérables représentent-ils un risque pour les développeurs de logiciels ?

Les développeurs utilisent les serveurs MCP pour enrichir leurs sessions de codage assisté par l’IA et de vibe coding, par exemple en s’intégrant à GitHub pour récupérer des informations sur les problèmes d’un dépôt de code.

Dans le même temps, l’ordinateur portable d’un développeur est souvent une cible de choix pour les acteurs malveillants, car il contient fréquemment des clés d’API, des identifiants, de la propriété intellectuelle et d’autres informations sensibles donnant accès à des environnements hautement privilégiés, à des bases de données et à une infrastructure cloud.

Imaginez également à quel point les développeurs sont occupés et combien leur travail implique de passer rapidement d’un contexte à un autre. Ce rythme effréné les expose au risque d’agir dans la précipitation, sans trop réfléchir, et de fonctionner en pilote automatique pour de nombreuses tâches quotidiennes :

• Vous ajoutez une nouvelle dépendance open source pour résoudre un problème ? Ouvrez le terminal et exécutez npm install <package>

• Vous ajoutez un nouveau serveur MCP ? Ouvrez le fichier de définition MCP de Cursor .cursor/mcp.json et définissez-en un nouveau

Malheureusement, les développeurs n’examinent pas suffisamment le code source des dépendances tierces qu’ils ajoutent à un projet, et il en va de même pour le code source des serveurs MCP.

Serveur MCP vulnérable

Créons un serveur MCP simple qui applique délibérément des pratiques de codage vulnérables et non sécurisées.

Ce serveur MCP fournira aux clients MCP, comme Cursor, des fonctionnalités leur permettant de rechercher des informations sur des packages dans le registre npm.

Voici le code source principal de la fonctionnalité de recherche de packages npm exposée par un serveur MCP :

const server = new McpServer({
  name: "npm JavaScript package management tools",
  version: "1.0.0",
  description: "Provides tools to get information about open source npm packages from the npmjs registry"
});

server.tool(
  "getNpmPackageInfo",
  "Get information about an npm package",
  {
    packageName: z.string()
  },
  async ({ packageName }) => {    
    const output = execSync(`npm view ${packageName}`, {
      encoding: "utf-8",
    });

    return {
      content: [
        {
          type: "text",
          text: output
        },
      ],
    };
  }
);

Définir un nouveau serveur MCP pour Cursor

Que se passe-t-il donc si les développeurs ajoutent un nouveau serveur MCP à Cursor, VS Code ou à d’autres IDE ? Ajoutons un nouveau serveur MCP local qui repose sur un processus exécuté par un runtime Node.js :

{
    "mcpServers": {
      "npm-package-info": {
        "command": "node",
        "args": ["/Users/lirantal/projects/repos/mcp-server-npm"]
      }
}

Voyons maintenant comment un tel serveur MCP peut appliquer des pratiques de codage non sécurisées susceptibles de provoquer une attaque par injection de commandes.

Dans un onglet Cursor, saisissons par exemple :

What is the last release date of the nodemon npm package

Cursor va alors consulter les outils disponibles et trouver un outil appelé getNpmPackageInfo qu’il peut appeler. Cet outil attend une chaîne contenant le nom d’un package. Il extraira la chaîne nodemon de notre prompt, puis appellera l’outil avec ce paramètre.

Mais que se passe-t-il si le prompt contient des caractères shell d’injection de commandes qui contournent la commande npm info <package name> et en créent une nouvelle ?

Qu’est-ce qu’une injection de commandes ? En bref, dans les programmes Node.js côté serveur, une injection de commandes se produit lorsque des données fournies par l’utilisateur sont intégrées directement à une commande système exécutée par le serveur MCP, sans assainissement approprié. Un attaquant peut alors modifier la commande prévue et exécuter des commandes arbitraires du système d’exploitation sur le serveur.

Prenons cette preuve de concept, qui demande à Cursor de rechercher des informations sur la bibliothèque react; touch /tmp/hi:

En raison du code vulnérable du serveur MCP, qui s’appuie sur les API de processus enfant de Node.js comme suit :

   const output = execSync(`npm view ${packageName}`, {
      encoding: "utf-8",
    });

Les attaquants peuvent concevoir un prompt en interagissant de différentes manières avec le chat (par exemple, en utilisant des règles Cursor piégées ou d’autres techniques), ce qui peut entraîner une injection de commandes.

Exploiter les vulnérabilités d’injection de commandes dans les serveurs MCP

En résumé, la vidéo suivante montre comment des attaquants peuvent exploiter des serveurs MCP vulnérables pour mener des attaques par injection de commandes :

Play Video: How Attackers Can Exploit Vulnerable MCP Servers to Execute Command Injection Attacks

Si vous développez des serveurs MCP en Python ou en Golang, je vous recommande vivement de vous renseigner sur les méthodes permettant d’atténuer ces vulnérabilités d’injection de commandes :

• Comprendre les vulnérabilités d’injection de commandes en Go

• Injection de commandes en Python : exemples et prévention