Un serveur MCP peut lire des fichiers, interroger des bases de données et exécuter des commandes pour un modèle d’IA, si bien qu’une seule faiblesse expose beaucoup de choses. Découvrez comment fonctionnent, dans de vrais incidents, les ports ouverts, la prompt injection, l’empoisonnement d’outils, les paquets malveillants et les secrets divulgués, ainsi que les correctifs qui tiennent.
Un serveur MCP est un petit programme à la grosse mission : il donne à un modèle d’IA le pouvoir de lire des fichiers, d’interroger des bases de données, d’envoyer des e-mails et d’exécuter des commandes shell. C’est précisément pourquoi les vulnérabilités des serveurs MCP continuent de figurer dans les bulletins de sécurité. Environ un an après que le protocole s’est imposé, des chercheurs ont publié des failles critiques d’exécution de code à distance, ont découvert un paquet malveillant qui copiait discrètement chaque e-mail envoyé, et ont recensé 1 862 serveurs exposés sur l’internet public, dont un échantillon de 119 permettait à des inconnus de lister leurs outils sans le moindre identifiant.
Cet article passe en revue les failles de sécurité MCP les plus courantes, présente les incidents réels derrière chacune d’elles et se termine par une liste de contrôle applicable dès aujourd’hui. Chaque section associe une faille au correctif qui tient vraiment, pour que vous puissiez combler les brèches au lieu de simplement vous en inquiéter.
Une API web classique remplit une mission étroite et précise. Un serveur MCP ressemble davantage à une multiprise : il branche un système de fichiers, un client git, une base de données, un navigateur et une messagerie sur une seule connexion, et c’est le modèle qui décide quelle prise utiliser. Les serveurs locaux tournent généralement comme processus enfant avec les mêmes permissions que votre compte utilisateur. Un outil compromis peut donc lire les configurations SSH, les profils de navigateur, les identifiants cloud et chaque dossier de projet de la machine.
Les serveurs distants ne sont pas plus sûrs. Ils détiennent souvent des jetons OAuth pour plusieurs services à la fois, ce qui transforme une seule intrusion en accès à de nombreux systèmes.
Les logiciels classiques ont une seule frontière de confiance : des entrées non fiables entrent, des données validées sortent. MCP en compte au moins quatre.
Des modèles comme Claude Sonnet 5 et GPT 5.6 Sol sont conçus pour suivre des instructions, et ils ne savent pas séparer de façon fiable une instruction de l’utilisateur d’une instruction cachée dans un document qu’on leur a demandé de résumer. Cette seule faiblesse alimente la plupart des attaques décrites ci-dessous.
💡 Règle empirique : traitez chaque chaîne de caractères qui atteint le modèle comme du code non fiable, même lorsqu’elle provient d’un outil que vous avez installé vous-même.
La plus ancienne erreur de sécurité réapparaît : des services qui répondent à quiconque frappe à la porte.
De nombreux serveurs MCP locaux se lient à 0.0.0.0 au lieu de 127.0.0.1, ce qui les rend accessibles à toute personne présente sur le même réseau Wi-Fi. Les chercheurs ont surnommé NeighborJacking l’attaque qui en découle. Le MCP Inspector officiel, un outil de débogage, montre à quel point le problème peut être grave : les versions antérieures à 0.14.1 n’avaient aucune authentification entre le client du navigateur et le proxy local. Cela a donné la CVE-2025-49596, une faille d’exécution de code à distance notée 9,4 de gravité, où une page web malveillante pouvait envoyer des commandes à la machine d’un développeur pendant que l’Inspector tournait dans un autre onglet.
Le tableau est encore pire sur l’internet public. Le scan de Knostic a trouvé 1 862 serveurs MCP exposés. Sur les 119 testés, aucun ne demandait d’authentification avant de renvoyer sa liste d’outils. N’importe qui disposant d’un navigateur ou d’un script pouvait voir ce que chaque serveur était capable de faire et, dans bien des cas, l’appeler.
Même les serveurs protégés par un identifiant authentifient souvent la connexion puis n’autorisent rien. Quiconque entre peut appeler chaque outil, y compris les outils destructeurs. La spécification MCP définit un flux d’autorisation basé sur OAuth pour les serveurs distants, mais il est facultatif, et de nombreux développeurs le sautent pour une démo rapide qui finit par passer en production.
Les correctifs sont simples :
127.0.0.1 et validez l’en-tête Origin sur les transports HTTP pour bloquer le DNS rebinding.delete_record.
La faille MCP la plus dangereuse n’est pas un bug de code. C’est du texte. Le chercheur en sécurité Simon Willison appelle la configuration à risque la trifecta mortelle : un agent qui peut lire des données privées, ingérer du contenu non fiable et transmettre des informations vers l’extérieur. Donnez ces trois capacités au même agent, et un attaquant n’a besoin que de glisser quelques phrases.
Deux cas réels illustrent ce schéma :
Aucun des deux serveurs ne présentait de vulnérabilité classique. Tous deux ont simplement fait exactement ce qu’on leur demandait, mais sur ordre de la mauvaise partie.
L’empoisonnement d’outils déplace l’attaque dans les métadonnées de l’outil lui-même. Invariant Labs a publié la méthode en avril 2025 : un outil qui ressemble à une fonction add inoffensive porte des instructions cachées dans sa description, demandant au modèle de lire les fichiers SSH privés et de les envoyer vers l’extérieur par un paramètre. L’utilisateur voit « add two numbers » dans la boîte d’approbation. Le modèle voit la description complète et lui obéit.
Certaines variantes dissimulent la charge utile avec des caractères Unicode de largeur nulle ou des blocs Base64, si bien qu’un examen visuel rapide ne détecte rien d’anormal.
Le rug pull est la version patiente. Un serveur se comporte bien le premier jour, recueille les approbations, puis publie de nouvelles définitions d’outils via la notification tools/list_changed. La plupart des clients ne demandent pas une seconde approbation, ne figent pas de version et ne comparent pas de hash. Une astuce apparentée, le tool shadowing, permet à un serveur malveillant de réécrire la façon dont le modèle utilise les outils d’un serveur de confiance, car toutes les descriptions atterrissent dans la même fenêtre de contexte.
Ce qui fonctionne contre cette famille d’attaques :
Les serveurs MCP s’installent avec une seule commande, généralement npx ou uvx, qui télécharge et exécute du code depuis un registre public. En septembre 2025, Koi Security a signalé ce qu’on a décrit comme le premier serveur MCP malveillant trouvé dans la nature : un paquet npm nommé postmark-mcp qui copiait une véritable bibliothèque d’e-mails. La version 1.0.16 ajoutait une seule ligne qui mettait en copie cachée chaque e-mail sortant vers une adresse contrôlée par l’attaquant. Le paquet avait été téléchargé 1 643 fois avant d’être retiré.
Une seule ligne suffisait, car presque personne ne lit le code source d’un serveur installé pour gagner cinq minutes.
La deuxième famille est l’injection de commandes classique. Un outil prend un nom de fichier, une URL ou un nom de branche et l’insère dans une chaîne shell. Le proxy mcp-remote a été touché par ce schéma avec la CVE-2025-6514, notée 9,6 : se connecter à un serveur MCP non fiable pouvait déclencher l’exécution de commandes arbitraires du système d’exploitation sur la machine qui fait tourner le proxy.
Ses cousins sont partout :
| Type de faille | Déclencheur typique | Schéma plus sûr |
|---|---|---|
| Injection shell | Nom de fichier ou URL collé dans une chaîne de commande | Passer les arguments sous forme de tableau, jamais via un shell |
| Traversée de chemin | Séquences ../ ou liens symboliques dans un chemin de fichier | Résoudre le chemin réel, puis le comparer à une racine autorisée |
| SSRF | Un outil de récupération pointé vers des adresses internes | Bloquer les plages d’IP privées et les points de terminaison de métadonnées cloud |
| Injection SQL | Requêtes écrites par le modèle exécutées avec tous les droits | Requêtes paramétrées et rôle de base de données en lecture seule |
Une configuration MCP typique colle un jeton d’accès directement dans un fichier JSON. Ce fichier finit dans un dépôt versionné, synchronisé sur un lecteur cloud ou lu par un outil empoisonné à qui l’on a demandé de le chercher. La journalisation aggrave le problème : les serveurs qui affichent les charges utiles complètes des requêtes écrivent des jetons dans des fichiers de logs que personne ne renouvelle.
Le nettoyage est une tâche de routine, mais il est rarement fait. Chargez les secrets depuis des variables d’environnement ou un gestionnaire de secrets, émettez des jetons à courte durée de vie, lancez un scan des secrets dans votre CI et masquez les en-têtes d’autorisation de chaque ligne de log.
Un serveur qui n’a besoin de lire qu’une table reçoit un jeton de rôle de service pour toute la base de données. Un jeton GitHub qui atteint chaque dépôt transforme une seule issue injectée en fuite totale. La documentation de Supabase recommande elle-même un mode en lecture seule, limité au projet, par défaut, ce qui est le bon réflexe pour tout serveur.
Deux erreurs au niveau du protocole méritent un nom :
💡 Test rapide : si le jeton d’un serveur était collé dans un chat public aujourd’hui, quels dégâts pourrait-il causer ? Réduisez le périmètre jusqu’à ce que la réponse fasse moins mal.
Voici l’intégralité de cet article condensée dans un tableau que vous pouvez coller dans un modèle de pull request.
| Faille | À quoi cela ressemble | Correctif |
|---|---|---|
| Ports ouverts | Serveur lié à 0.0.0.0, sans identifiant | Lier à localhost, exiger des jetons |
| Prompt injection | L’agent obéit à un texte dans un ticket ou une issue | Séparer les droits de lecture et d’envoi, approuver les actions sortantes |
| Empoisonnement d’outils | Descriptions d’outils longues ou étranges | Afficher le texte complet, supprimer les caractères invisibles |
| Rug pull | Les outils changent après approbation | Figer les versions, calculer le hash des définitions |
| Paquet malveillant | Nom ressemblant à un paquet légitime sur npm | Vérifier l’éditeur, figer la version, relire les différences |
| Injection de commandes | Saisie utilisateur dans des chaînes shell | Tableaux d’arguments et listes d’autorisation |
| Fuite de secrets | Jetons dans des configurations JSON et des logs | Gestionnaire de secrets, durées de vie courtes |
| Périmètres trop larges | Jeton administrateur pour une tâche de lecture | Moindre privilège par serveur |
Journalisez chaque appel d’outil avec ses arguments et l’identité qui le sous-tend. Signalez l’apparition d’un nouvel outil ou la modification d’une définition. Limitez le débit des outils coûteux, renouvelez les jetons selon un calendrier et gardez un coupe-circuit d’urgence qui déconnecte tous les serveurs d’un seul geste. Relisez les journaux après la première semaine, car c’est généralement à ce moment que les comportements surprenants apparaissent.
Llama Guard 4 12B est un classifieur de sécurité que vous pouvez exécuter sur PicassoIA. Il renvoie un verdict sûr ou dangereux, accompagné de la catégorie de risque détectée. Ce n’est pas un détecteur spécialisé de prompt injection : traitez-le donc comme un signal d’alerte supplémentaire pour les descriptions d’outils et leur sortie, et non comme un filtre auquel vous pouvez vous fier seul.
Voici un flux de travail qui prend quelques minutes :
| Paramètre | Valeur suggérée | Pourquoi c’est utile |
|---|---|---|
| Temperature | 0 à 0,2 | Verdicts stables pour un même texte |
| Max Completion Tokens | 512 ou moins | Le verdict est court, donc une longueur supplémentaire ne sert à rien |
| System Prompt | Règles courtes et précises | Des règles précises produisent moins de réponses vagues |
| Image Input | Facultatif | Utile pour vérifier la capture d’écran d’une boîte de dialogue d’outil |
💡 Demandez un second avis : collez le même texte dans Gemini 3.5 Flash et demandez-lui de lister chaque phrase qui donne une instruction à un assistant d’IA. Deux modèles différents qui ne sont pas d’accord constituent un signal utile.
Les analyses de sécurité, les runbooks et les supports de formation internes ont tous besoin d’images qui ressemblent à la vraie vie, et non à des photos de banques d’images trop convenues. Picasso IA transforme une description textuelle en image photoréaliste en quelques secondes, ce qui vous permet de créer un visuel pour chaque faille décrite dans cet article sans séance photo.
Essayez p-image pour des scènes rapides et nettes, Seedream 4.5 pour un détail riche ou Flux 2 Pro lorsque vous voulez un contrôle précis de la composition. Décrivez le sujet, la lumière et l’objectif, puis lancez la génération et ajustez un détail à la fois. Parcourez toutes les options sur picassoia.com/en/all-models, choisissez un modèle et créez votre première image dès aujourd’hui.
Choisissez votre langue
