Serveurs MCP, maillon faible : chiffres GhostSplice, voies de fuite et checklist

TL;DR

• Un serveur MCP n'est pas un plugin, c'est un détenteur de credentials qui parle à votre agent à chaque appel : ses descriptions d'outils et ses résultats d'outils arrivent dans le contexte du modèle avec le même poids que vos propres instructions.
• GhostSplice montre que l'alignement du modèle n'est pas une défense : un ordre de vol donné en un seul bloc est refusé 100% du temps par GPT-4o, Gemini 2.0 Flash et Llama 3.3 ; le même ordre découpé entre une description d'outil et un résultat d'outil est exécuté 100% du temps.
• Le client compte autant que le modèle : Claude Haiku 4.5 refuse tout via l'API et cède à 100% au test en trois fragments lancé dans Cursor.
• La supply chain est déjà un fil sous tension : CVE-2025-6514 a touché mcp-remote, un proxy OAuth téléchargé plus de 400,000 fois, avec une injection de commande déclenchée par un serveur malveillant.
• La détection au niveau protocole de Cloudflare et WriteGuard sont les premiers vrais contrôles en entreprise, mais ils exigent Zero Trust avec inspection TLS, et un serveur stdio local n'y apparaît jamais.
• Pour un développeur solo ou une petite équipe, la défense est manuelle : inventaire, provenance, tokens à portée limitée, validation humaine sur chaque écriture, et sortie d'outil traitée comme de la donnée.

Ce que disent les sources

Un serveur MCP fait le pont entre votre agent et un service externe, il stocke donc à votre place ce qu'il faut pour se connecter : tokens, clés d'API, credentials de compte de service. L'analyse des fuites publiée le 17 août part d'un constat brut : les tokens sont collés directement dans des chaînes de configuration et restent lisibles sur le disque, à un commit précipité d'un dépôt Git s2. La même analyse place le sur-provisionnement des droits en deuxième faille : les droits larges accordés pendant le développement partent en production tels quels, si bien qu'une seule compromission expose bien plus que l'usage réel ne le justifiait s2. La quatrième faille est la prompt injection : un agent lit tout ce que ses outils lui rapportent, une page web, un ticket, un document interne, et une instruction cachée dans ce contenu est suivie comme si elle venait de vous, en utilisant des outils légitimes pour exposer ce qu'ils devaient protéger s2.

La troisième faille est la supply chain. CVE-2025-6514 touchait mcp-remote, un proxy OAuth téléchargé plus de 400,000 fois : un serveur malveillant pouvait déclencher une injection de commande sur la machine du développeur, exécuter du code et repartir avec les credentials. Un seul package npm populaire, installé en une ligne, et la porte était ouverte s3.

L'écosystème a grandi plus vite que ses garde-fous. Le registre officiel dépasse 9,600 serveurs publiés, les déploiements de serveurs distants ont été multipliés par cinq depuis mai 2025, n'importe qui peut publier, et il n'y a aucune validation centrale ; votre agent accorde à une entrée au hasard la même confiance qu'à un outil officiel s4. La NSA a publié en mai un guide de sécurité dédié à MCP, où elle affirme que l'adoption du protocole a devancé la construction de ses protections s5.

GhostSplice, nommé par le groupe de recherche ASSET, fait exécuter l'exfiltration par l'agent lui-même. Au lieu d'écrire l'ordre de vol complet, le serveur malveillant le découpe : un fragment dans une description d'outil, l'autre dans le résultat que cet outil renvoie. Chaque morceau paraît inoffensif isolément ; l'agent recompose tout ce qui entre dans son contexte et exécute l'instruction entière en toute bonne foi s1. Les chiffres sont le point central. Avec l'instruction donnée en un seul bloc, GPT-4o, Gemini 2.0 Flash et Llama 3.3 refusent 100% du temps. Avec l'instruction fragmentée, les trois obéissent 100% du temps s1. Les modèles Claude résistent mieux en surface, mais Claude Haiku 4.5 refuse tout via l'API et cède à 100% au test en trois fragments lancé dans Cursor : le même modèle refuse dans un client et exfiltre dans un autre, selon les protections que le client ajoute ou non s1. Ce que les tests ont volé : clés SSH, secrets d'environnement, code source, données clients, sur des projets isolés avec de fausses clés, avec une méthode publiée et reproductible s1. Le même labo a publié Ghostcommit en juin, qui cachait ses instructions dans des fichiers PNG référencés par les conventions du projet, puis encodait les secrets volés dans le code source sous forme d'entiers ; la fragmentation d'instructions est une famille d'attaques, pas un cas isolé s1. Deux prérequis tiennent : le serveur malveillant doit déjà être connecté à votre agent, et l'agent doit avoir le droit de lire les fichiers visés s1.

Côté entreprise, Cloudflare appelle "shadow MCP" les serveurs non approuvés que les développeurs branchent sur leurs agents. Depuis la mise à jour de la spec, tout client MCP conforme envoie un en-tête MCP-Protocol-Version, et Gateway inspecte cet en-tête sur tout le trafic TLS analysé, ce qui donne à une équipe sécurité un tableau de bord des serveurs uniques, des utilisateurs et des volumes de requêtes s6. La version la plus récente de la spec ajoute les en-têtes Mcp-Method et Mcp-Name, qui exposent l'opération demandée et le nom de l'outil sans ouvrir le corps de la requête, de sorte que le réseau peut distinguer un agent qui lit un ticket d'un agent qui en supprime cinquante. Les règles de Cloudflare couvrent deux cas, le pur shadow MCP (un serveur jamais approuvé) et le contournement de portail (un serveur approuvé atteint en direct), et les deux sont bloqués par la même règle de base s6.

WriteGuard, ouvert en bêta privée, classe chaque outil de chaque serveur MCP dans un niveau de risque et applique une politique différente par niveau : une lecture passe sans friction ; une écriture contenue, comme poster un commentaire, passe mais est signée comme venant d'un agent au nom d'un humain identifié, avec un événement d'audit envoyé vers un journal central ; une action critique, comme fusionner du code, déployer en production ou supprimer en masse, est bloquée avant que le serveur ne la traite s7. L'exemple GitLab du billet : lire une merge request passe, commenter passe avec attribution, fusionner est refusé tant qu'un humain ne le fait pas. L'agent garde les permissions de l'employé qu'il sert, mais chaque écriture porte deux signatures, la personne et la session de l'agent. Cloudflare décrit son propre usage interne : son portail connecte 27 serveurs MCP, contre 13 en avril s7.

Les limites sont réelles. WriteGuard est en bêta privée sur inscription, et la détection Gateway exige un déploiement Cloudflare Zero Trust avec inspection TLS activée s7. La détection ne voit que le trafic réseau qu'elle déchiffre : un serveur MCP local tournant en stdio comme simple processus sur votre machine reste invisible pour Gateway, et c'est ainsi que tournent la plupart des serveurs installés par les développeurs s6. Aucun de ces outils ne corrige le mécanisme que GhostSplice met en évidence. Les chercheurs d'ASSET disent que la solution est de traiter la sortie d'un outil comme de la donnée, jamais comme des instructions, et que cette séparation n'existe pas encore nativement dans les agents. Leurs trois recommandations : empêcher qu'une valeur produite par un outil alimente sans contrôle les arguments d'un autre outil, garder la possibilité de refuser à la main chaque invocation d'outil, et traiter toute annotation venant d'un serveur non vérifié comme hostile par défaut s1.

Verdict : ce qui vous protège et ce qui ne vous protège pas

À faire lundi

• Sortez la liste des serveurs MCP réellement connectés à chacun de vos agents et retirez tous ceux que vous n'avez pas utilisés depuis un mois.
• Pour chaque serveur restant, notez qui le publie et lisez ce qu'il fait de vos données avant de le garder ; supprimez tout serveur venu d'un thread plutôt que de l'éditeur.
• Remplacez chaque credential partagé ou maître dans une config MCP par un token dédié, limité au minimum dont ce serveur a besoin, et mettez-y une date de rotation.
• Vérifiez qu'aucun de vos fichiers de config MCP n'est suivi par Git, et ajoutez-les à .gitignore quand ils le sont.
• Épinglez la version de chaque package MCP que vous installez, et cherchez dans votre lockfile les versions de mcp-remote couvertes par CVE-2025-6514.
• Activez l'approbation manuelle pour tout outil qui écrit, fusionne, déploie ou supprime, et gardez-la active dans chaque client que vous utilisez.
• Relisez une fois les descriptions d'outils de chaque serveur tiers, en cherchant des instructions adressées au modèle plutôt qu'à vous.
• Si vous utilisez Cloudflare Zero Trust, activez l'inspection TLS et construisez le tableau de bord shadow MCP à partir de l'en-tête MCP-Protocol-Version.

Aller plus loin

• Lisez l'analyse complète de GhostSplice pour la matrice de tests par modèle et par client, et pour les trois mitigations proposées par les chercheurs s1.
• Cherchez Ghostcommit, l'attaque de juin du même labo, pour voir comment les instructions se cachaient dans des fichiers PNG et comment les secrets volés étaient encodés en entiers dans le code source s1.
• Passez les quatre voies de fuite de l'analyse du 17 août en revue sur vos propres configs : stockage en clair, sur-provisionnement, supply chain, prompt injection s2.
• Lisez la fiche NVD de CVE-2025-6514 et vérifiez quelles versions de mcp-remote sont touchées avant de faire confiance à un proxy OAuth dans votre stack s3.
• Lisez les design considerations de la NSA pour MCP : c'est la seule checklist indépendante des éditeurs écrite pour les équipes qui déploient de l'automatisation par agents s5.
• Étudiez les en-têtes MCP-Protocol-Version, Mcp-Method et Mcp-Name dans le billet de Cloudflare même si vous n'utilisez pas Cloudflare : n'importe quel proxy que vous contrôlez peut les journaliser s6.
• Empruntez les quatre niveaux de risque de WriteGuard (lecture seule, impact minimal, écriture contenue, critique) comme grille de revue des outils que vos propres serveurs exposent s7.
• Parcourez le README du registre officiel pour comprendre ce que la publication exige et ce qu'elle ne vérifie pas s4.

Sources

• Malicious MCP servers can split exfiltration orders to bypass model refusals (GhostSplice), The Hacker News. Pourquoi le lire : le seul endroit avec les chiffres par modèle et par client, plus les mitigations des chercheurs.
• How MCP servers can expose enterprise secrets, The Hacker News. Pourquoi le lire : les quatre voies de fuite exposées dans l'ordre, utilisables comme checklist d'audit.
• CVE-2025-6514: mcp-remote command injection, NIST NVD. Pourquoi le lire : les versions touchées et la sévérité de la première faille supply chain MCP largement installée.
• Official Model Context Protocol registry, modelcontextprotocol on GitHub. Pourquoi le lire : montre comment fonctionne la publication et pourquoi la présence dans le registre n'est pas un signal de confiance.
• NSA releases security design considerations for AI-driven automation leveraging MCP, NSA. Pourquoi le lire : un guide de conception indépendant des éditeurs pour les équipes qui déploient MCP à grande échelle.
• Detecting and blocking shadow MCP at the protocol level, Cloudflare blog. Pourquoi le lire : explique les en-têtes de la spec qui rendent le trafic MCP visible sur le réseau.
• Bring secure MCP connectivity to your enterprise with MCP Server Portals and WriteGuard, Cloudflare blog. Pourquoi le lire : le modèle de risque par outil et le design d'identité à double signature, avec un exemple GitLab concret.

FAQ

Utiliser un modèle plus sûr me protège-t-il de GhostSplice ?

Non. L'attaque ne demande jamais rien d'interdit en un seul morceau, donc l'entraînement au refus ne se déclenche pas. Le même Claude Haiku 4.5 a tout refusé via l'API et obéi à 100% dans Cursor ; ce sont les protections du client qui ont décidé du résultat, pas le modèle.

Je suis développeur solo, un outil Cloudflare est-il pour moi ?

Pas aujourd'hui. La détection Gateway exige un déploiement Zero Trust avec inspection TLS, WriteGuard est une bêta privée, et les deux sont aveugles aux serveurs stdio locaux. La checklist ci-dessus est la version solo des mêmes contrôles.

Un serveur listé dans le registre officiel est-il sûr ?

Être listé n'est pas être validé. Le registre dépasse 9,600 serveurs sans revue centrale, et votre agent fait autant confiance à une entrée du registre qu'à un outil d'éditeur. Jugez la provenance et lisez le code, pas la fiche.

Quel est le changement le plus rentable ?

Des tokens dédiés, à portée minimale, par serveur, avec rotation comme pour des secrets de production. Les credentials maîtres en clair dans les fichiers de config sont la première voie de fuite, et ils rendent toutes les autres défaillances, de CVE-2025-6514 à la prompt injection, bien plus coûteuses.