2026-07-31 · RECHERCHE · L'équipe Offensive Technology

Sécurité des serveurs MCP distants : ce que révèle un recensement de 19,321 serveurs publiés

La moitié des serveurs du registre officiel Model Context Protocol sont distants. Nous avons extrait l'ensemble de la population publiée le 31 July 2026, soit 19,321 serveurs uniques, et analysé leur mode de déploiement. 50.0% exposent un endpoint distant, une URL à laquelle votre agent IA se connecte via le réseau afin que le code s'exécute sur la machine d'un tiers et que vous ne voyiez que les résultats renvoyés. L'autre moitié, 48.3%, sont des paquets locaux qui s'exécutent sur votre propre machine où vous pouvez les inspecter. Ce simple arbitrage résume le problème de sécurité enfoui dans chaque installation MCP : ajoutez-vous une bibliothèque sous votre contrôle, ou raccordez-vous votre agent au serveur d'un inconnu ? De plus, 30.5% des serveurs vous demandent un secret avant de pouvoir s'exécuter, et la moitié distante renvoie vers 7,420 hôtes tiers distincts. Aucun de ces chiffres ne nomme un serveur, une entreprise ou une personne. Ils représentent les métriques de base d'un écosystème que la plupart des équipes adoptent plus vite qu'elles ne l'auditent.

Ce qu'est réellement un serveur MCP distant

Le Model Context Protocol est l'architecture qui permet à un agent IA d'appeler des outils externes : lire un ticket, interroger une base de données, ouvrir une pull request. Un serveur expose un ensemble d'outils, l'agent en choisit un, envoie des arguments et réintègre la réponse dans son contexte de travail. Ce serveur peut vous joindre de deux manières. Un local serveur est un paquet, sur npm, PyPI ou une image OCI, que vous installez et exécutez vous-même. Il dialogue avec l'agent via stdio sur votre propre machine. Un distant serveur est une URL. Votre agent ouvre une connexion vers celle-ci, transmet les appels d'outils et reçoit les résultats en flux.

La différence réside dans la frontière de confiance. Avec un serveur local, le code, les dépendances et les appels réseau sortants se trouvent tous sur un matériel que vous contrôlez et pouvez inspecter. Avec un serveur distant, le code réside sur l'infrastructure de l'opérateur. Vous ne le voyez pas, vous ne pouvez pas verrouiller sa version exacte par un hash comme vous le feriez pour un paquet, et chaque argument envoyé par votre agent, ainsi que tout ce que votre agent a inclus comme contexte pour l'appel, est transmis à cet opérateur. Les résultats d'outils renvoyés sont ensuite acceptés par l'agent comme s'il s'agissait de son propre raisonnement. Ce canal de retour est précisément là où résident le tool-poisoning et l'injection indirecte de prompt.

Comment les 19,321 serveurs publiés sont déployés

Voici l'ensemble de la population, ventilée selon la manière dont chaque serveur communique avec votre agent. La part distante est l'élément le plus marquant, car c'est celle où la frontière de confiance quitte votre machine.

La répartition exacte mérite d'être énoncée clairement, car les moitiés arrondies masquent un détail. Sur les 19,321 serveurs, 8,642 (44.7%) sont uniquement distants, sans aucun paquet local exécutable à la place. Un autre groupe de 1,014 (5.2%) proposent les deux un endpoint distant et un paquet local, vous laissant le choix. 9,323 (48.3%) sont uniquement des paquets locaux, et un solde résiduel de 342 (1.8%) n'a déclaré ni paquet ni endpoint fonctionnel. Ainsi, lorsqu'un serveur est distant, il l'est le plus souvent sans alternative : l'utiliser implique d'accepter l'endpoint tiers, ou de ne pas l'utiliser du tout.

La demande d'identifiants : un tiers des serveurs réclament vos clés

Un outil qui lit vos tickets GitHub ou interroge votre pile d'observabilité doit s'authentifier quelque part, les demandes de secrets sont donc prévisibles. Le chiffre mérite néanmoins d'être souligné : 30.5% des serveurs publiés, soit 5,888 d'entre eux, déclarent au moins un identifiant ressemblant à un secret, une variable d'environnement ou un en-tête d'authentification dont le nom contient un jeton comme KEY, TOKEN, SECRET, PASSWORD, ou AUTH. Environ un serveur sur trois exige un identifiant actif avant de faire quoi que ce soit.

Associez cela à la proportion de serveurs distants, et le risque se précise. Lorsque vous transmettez un identifiant à un serveur local, le secret reste dans votre environnement et l'outil l'utilise depuis votre machine. Lorsque vous transmettez un identifiant à un serveur distant, soit vous le communiquez à l'opérateur, soit vous l'autorisez à agir en votre nom avec celui-ci. Dans les deux cas, l'opérateur devient détenteur de votre clé. Si cet opérateur gère mal ses logs ou se fait compromettre, le secret restreint à un outil tombe entre les mains d'un attaquant. Le moindre privilège n'est pas optionnel : un serveur ne doit recevoir qu'un jeton strictement limité à ce dont ses outils ont besoin, et rien de plus.

Où se trouvent réellement les endpoints distants

La moitié distante ne se résume pas à une poignée de clouds de confiance. Les 9,656 serveurs disposant d'un endpoint distant se répartissent sur 7,420 hôtes distincts. La longue traîne est bien réelle : 98.1% de ces hôtes n'hébergent qu'un seul serveur, ce qui représente une multitude d'opérateurs indépendants, autant de tiers qu'il vous faudrait évaluer. Si vos agents adoptaient le registre dans son intégralité, ils ouvriraient des connexions vers des milliers d'endpoints différents, gérés pour la plupart par des entités inconnues.

À l'autre extrémité de la distribution se trouve la concentration. L'hôte passerelle le plus important concentre 13.5% de tous les serveurs distants, et les dix hôtes les plus sollicités représentent 18.9% des endpoints distants à eux seuls. Environ un quart des serveurs distants s'appuient sur un hôte mutualisé et multi-tenant plutôt que sur leur propre domaine. C'est le fonctionnement à double tranchant de toute marketplace : quelques agrégateurs captent une part importante du trafic, ce qui est pratique, mais implique aussi qu'un seul opérateur ou une seule panne impacte une large fraction de l'écosystème. Nous ne nommons pas ces hôtes ; l'important est la structure, pas l'adresse.

La fausse alerte : l'Unicode masqué

Une attaque MCP bien documentée dissimule des instructions destinées à l'agent dans les champs textuels publiés par un serveur, en utilisant des caractères invisibles : des point de code Unicode de type tag, des liants à largeur nulle, des contrôles bidirectionnels, des séquences d'échappement ANSI. L'agent les lit, pas l'examinateur humain. Nous avons analysé chaque champ textuel visible par le modèle pour l'ensemble des 19,321 serveurs afin de rechercher ces classes de points de code. Le résultat est totalement nul : 0 serveur sur 19,321 ne contenait de caractère non imprimable ou de classe d'injection dans les métadonnées de son registre.

C'est une bonne nouvelle assortie d'une limite, et cette limite a son importance. Le registre publie le nom, le titre et la description d'un serveur, mais pas les descriptions des outils individuels qu'il expose, qui sont pourtant les champs chargés dans le contexte de l'agent à chaque appel et la cible la plus intéressante pour une attaque par instructions masquées. Notre résultat nul indique que la couche de métadonnées du registre est propre aujourd'hui. Il ne garantit pas que les outils derrière ces serveurs le soient, car le registre ne fournit pas cette surface pour une lecture passive. Le constat honnête est donc restreint : au niveau que nous pouvons mesurer sans toucher au serveur de quiconque, le canal des caractères invisibles n'est pas exploité.

L'analyse du registre du point de vue de l'attaquant

Examinez ces chiffres du point de vue de celui qui évalue la valeur d'une mesure de sécurité. Un attaquant cherchant à s'infiltrer dans une organisation via ses outils IA dispose ici de deux stratégies évidentes, et le recensement montre que toutes deux sont viables à grande échelle. La première consiste à opérer un serveur : publier un outil utile, le faire installer, puis recevoir légitimement chaque requête envoyée par l'agent et contrôler chaque résultat qu'il lit. Avec la moitié du registre déjà distante, un serveur distant supplémentaire ne suscite aucune suspicion. La seconde consiste à compromettre un opérateur qui détient déjà la confiance de nombreuses équipes, et la concentration au sommet de la distribution des hôtes indique exactement où se situe ce levier.

Le chiffre relatif aux secrets joue le rôle de multiplicateur. Un tiers des serveurs se voient déjà confier un secret, de sorte qu'un serveur piégé ou compromis ne se limite pas à intercepter le trafic ; il peut détenir des clés donnant accès aux systèmes sous-jacents. Il s'agit du même élargissement d'empreinte que nous décrivons dans notre guide sur ce que les attaquants peuvent réellement voir de votre entreprise, transposé une couche plus à l'intérieur : la surface n'est plus seulement votre DNS public et vos services exposés, c'est l'ensemble des serveurs externes avec lesquels vos agents sont autorisés à dialoguer. Chacun d'eux est une dépendance, et c'est par les dépendances que débutent les intrusions modernes.

Comment garder les serveurs MCP distants sous contrôle

Rien de tout cela ne remet en cause l'usage des serveurs MCP distants. Cela plaide pour les traiter comme les dépendances tierces qu'ils sont réellement. Si vous exploitez des agents connectés à des outils MCP, voici les recommandations essentielles.

• Maintenez une liste d'autorisation, pas un registre ouvert. Déterminez quels serveurs spécifiques vos agents peuvent utiliser et verrouillez-les. Le fait que la moitié du registre soit distante signifie que vous choisissez de faire confiance à un opérateur pour la moitié d' entre eux. Choisissez donc de manière délibérée plutôt que d'installer au fil des découvertes.
• Privilégiez le local lorsque les deux existent. Pour les 5.2% qui proposent à la fois un paquet et un endpoint, le paquet local conserve le code et son trafic sur votre machine. Optez pour cette option lorsque l'outil n'a pas réellement besoin d'être distant.
• Restreignez le périmètre de chaque identifiant à l'outil. Avec 30.5% des serveurs réclamant un secret, émettez un jeton strictly limité aux besoins des outils du serveur, appliquez une rotation, et ne confiez jamais de clé aux privilèges larges à un serveur que vous n'avez pas audité.
• Traitez les sorties d'outils comme des entrées non fiables. Les résultats renvoyés par un serveur peuvent contenir des instructions destinées à votre agent. Limitez ce que l'agent est autorisé à faire avec ces données, et ne laissez pas le résultat d'un outil déclencher silencieusement des actions privilégiées.
• Sachez qui se trouve à l'autre bout. Un endpoint distant renvoie vers l'hôte d'un tiers. Pour les serveurs dont vous dépendez, identifiez l'opérateur, et gardez à l'esprit que la majorité des hôtes de ce registre ne desservent qu'un seul serveur géré par une seule entité.

Méthodologie, pour que les sceptiques puissent accorder leur confiance aux chiffres

Le jeu de données nous appartient, constitué à partir d'une source publique, sous forme agrégée uniquement. Nous avons interrogé l'API de listing publique du registre officiel Model Context Protocol et parcouru l'intégralité du catalogue le 31 July 2026, en enregistrant 62,430 entrées de version. Nous avons réduit cela aux 19,321 serveurs marqués comme étant la version actuelle la plus récente, ce qui constitue la population active dédupliquée et le dénominateur de chaque pourcentage présenté ici. Le déploiement a été classé à partir des paquets et endpoints distants déclarés par chaque serveur ; le chiffre des identifiants comptabilise toute variable d'environnement ou en-tête d'authentification déclaré dont le nom contient un jeton assimilable à un secret ; la concentration des hôtes a été calculée en résolvant le nom d'hôte de chaque endpoint distant ; et la recherche de caractères masqués a testé chaque champ textuel par rapport au bloc Unicode tag, aux caractères de formatage de largeur nulle et bidirectionnels, aux séquences d'échappement ANSI, ainsi qu'aux autres points de code de contrôle et d'usage privé.

Nous avons uniquement consulté l'API publique du registre. Nous ne nous sommes connectés à aucun des serveurs répertoriés, n'avons envoyé aucune requête à l'endpoint d'un quelconque opérateur et n'avons collecté aucune donnée individuelle. La lecture d'un catalogue public est un acte passif ; interagir avec les hôtes qu'il contient ne le serait pas, et nous ne l'avons pas fait.

Ce que cette étude ne démontre pas

Un chiffre sans ses limites relève du marketing, voici donc les limites de ces données.

• Il s'agit d'un seul registre. Le registre officiel constitue le catalogue central, mais il existe des serveurs qui n'y sont jamais publiés, et d'autres annuaires répertorient leurs propres serveurs. Cette étude mesure la population publiée et découvrable, pas l'intégralité des serveurs existants.
• Déclaré, pas observé. Le mode de déploiement et les identifiants proviennent des déclarations de chaque serveur dans sa fiche de registre. Un serveur pourrait exiger un secret non listé, ou proposer un paquet qu'il ne prend pas réellement en charge. Nous avons mesuré le manifeste, pas une installation en direct.
• Le caractère distant est une surface de risque, pas un verdict. Un serveur distant n'est pas insécurisé du simple fait qu'il est distant. De nombreux serveurs sont correctement exploités par des opérateurs sérieux. Les 50.0% représentent l'ampleur de la décision de confiance, pas un décompte d'acteurs malveillants.
• Le résultat nul a un périmètre précis. L'absence totale de détection de caractères masqués ne concerne que les champs du registre situés au niveau du serveur. Les descriptions spécifiques à chaque outil, chargées dans l'agent à chaque appel, ne sont pas publiées pour une lecture passive, cela ne constitue donc pas un brevet d'innocuité pour les outils eux-mêmes.
• Il s'agit d'une photographie à un instant T. Le registre s'enrichit chaque jour. Ces chiffres décrivent la situation au 31 July 2026, non une tendance, et une nouvelle extraction le mois prochain modifiera ces données.

Foire aux questions

L'utilisation des serveurs MCP distants est-elle sûre ?

Un serveur MCP distant n'est sûr qu'à la hauteur de la fiabilité de l'opérateur qui l'exécute, car votre agent envoie des requêtes et lit les résultats depuis l'endpoint de cet opérateur. Dans ce recensement, 50.0% des serveurs étaient distants, et tous utilisaient HTTPS. Le transport n'est donc pas la faille. Le problème est la confiance. Verrouillez les serveurs que vous avez évalués et attribuez à chacun des identifiants au moindre privilège.

Quelle est la différence entre un serveur MCP local et un serveur MCP distant ?

Un serveur local s'exécute sous forme de paquet sur votre propre machine, de sorte que son code et ses appels réseau peuvent être inspectés. Un serveur distant est une URL à laquelle votre agent se connecte, le code s'exécute donc sur l'infrastructure d'un tiers et vous ne voyez que les réponses. Dans ce recensement, 48.3% étaient locaux uniquement, 44.7% distants uniquement, et 5.2% proposaient les deux.

Combien de serveurs MCP existent-il ?

Le registre officiel comptait 19,321 serveurs publiés uniques lorsque nous avons extrait l'ensemble de la population le 31 July 2026, en ne comptabilisant que la dernière version de chacun. Il évolue rapidement, considérez donc ce chiffre comme un instantané daté.

Les serveurs MCP nécessitent-ils des clés API ou des identifiants ?

Beaucoup en nécessitent. Dans ce recensement, 30.5% des serveurs déclaraient au moins un identifiant assimilable à un secret, ainsi environ un serveur sur trois demande une clé ou un jeton avant de s'exécuter. Cela élargit le rayon d'impact si le serveur ou son opérateur est compromis.

Un serveur MCP peut-il voler vos données ?

Un serveur malveillant ou compromis peut lire chaque requête envoyée par votre agent et renvoyer des résultats piégés dans le contexte de l'agent, ce qui constitue le principe du tool-poisoning et de l'injection de prompt. Il ne peut pas dépasser le cadre des outils et des identifiants que vous lui accordez, le moindre privilège et une liste d'autorisation auditée constituent donc la meilleure défense.

Le registre MCP est-il contrôlé ?

Non. L'inscription est une simple publication, pas un audit de sécurité. Le registre indique où se trouve un serveur, non si son opérateur est digne de confiance. Les serveurs distants pointaient vers 7,420 hôtes, dont 98.1% n'hébergeaient qu'un seul serveur, la majorité de la supply chain est donc constituée d'opérateurs qu'il vous faudrait évaluer individuellement.

Quels sont les risques de sécurité liés aux serveurs MCP ?

Les principaux risques sont le renvoi de sorties d'outils piégées vers votre agent, un opérateur distant qui voit et enregistre chaque requête, l'exposition d'identifiants lorsqu'un serveur exige des clés, et le risque de concentration lorsque de nombreux serveurs se trouvent derrière une seule passerelle. Dans ce recensement, les techniques exotiques comme l'Unicode masqué étaient absentes des métadonnées du registre, 0 sur 19,321, le risque immédiat concerne donc la confiance et les accès, pas le codage.

Lectures connexes

• Ce que les attaquants peuvent réellement voir de votre entreprise La surface d'attaque que cet article étend vers l'intérieur jusqu'à l'outillage de vos agents.
• Est-ce que p=none suffit ? La même méthode de mesure passive, appliquée à l'authentification de la messagerie.
• L'autorisation avant tout. Pourquoi chaque mesure que nous publions reste du bon côté de la loi.