Au-delà du tool poisoning : ce qu'un serveur MCP distant malveillant peut vraiment faire

De quoi s’agit-il ?

Le 21 mai 2026, l’article relu par les pairs Beyond Tool Poisoning: Attack Surfaces of Malicious Remote MCP Servers Across LLM Platforms a été publié dans Electronics (vol. 15, n° 10, article 2214 ; soumis le 27 avril 2026). Le Model Context Protocol (MCP), introduit par Anthropic fin 2024, est devenu le standard de fait pour relier un hôte LLM à des outils externes. C’est son mode distant qui est étudié ici : l’utilisateur ajoute un serveur tiers via une simple URL, ce qui transfère silencieusement une large part de la surface d’attaque de l’hôte vers une infrastructure exploitée par une partie anonyme.

La plupart des travaux antérieurs sur la sécurité MCP portaient sur le Tool Poisoning Attack (TPA) — des directives cachées dans la description d’un outil qui détournent le modèle au moment de l’enregistrement. Cet article soutient que la description n’est qu’un coin de l’espace de menace et réorganise le problème autour d’une question plus utile : l’hôte LLM participe-t-il, ou non, à la production du résultat malveillant ?

Comment ça marche

Les auteurs séparent le comportement d’un serveur malveillant en deux catégories et testent cinq scénarios contre ChatGPT, Claude Desktop et Gemini CLI.

Catégorie       Où l'attaque se conclut            Scénarios évalués
-------------   -------------------------------   ----------------------------------------
LLM-passive     Dans le serveur, à partir des       File Content Exfiltration
                seuls arguments transmis par         Email Content Exfiltration
                l'hôte. Le raisonnement du LLM
                ne voit jamais le comportement
                malveillant.

LLM-active      Le LLM est le canal de livraison.   Conditional URL Substitution
                Le serveur amène le modèle à         Malicious Code Augmentation
                produire/relayer la charge, via      Image Steganography
                la DESCRIPTION de l'outil (C1)
                ou sa RÉPONSE (C2).

Ce découpage compte car la frontière de défense décisive diffère selon la catégorie. Pour les attaques LLM-passives, la seule défense est le filtrage avant invocation des données que l’hôte envoie à l’outil — une fois les arguments partis, le modèle ne peut plus intervenir. Pour les attaques LLM-actives, la frontière est le raisonnement sur le contenu du modèle : traite-t-il une description d’outil comme faisant autorité, et valide-t-il une réponse d’outil avant de la relayer ?

Chaque résultat est mesuré avec deux métriques : le Attack Success Rate (ASR), et un Self-Reporting Rate (SRR) qui indique si une attaque réussie reste visible pour un utilisateur attentif ou se déroule en silence. La motivation n’est pas hypothétique : l’article cite un incident de septembre 2025 où un serveur MCP Postmark non officiel (plus de 1500 téléchargements hebdomadaires) a été modifié pour mettre silencieusement en copie cachée (BCC) chaque e-mail sortant vers une adresse pirate, sans être détecté pendant des semaines.

Pourquoi c’est important

Trois constats ressortent, et chacun ébranle une hypothèse confortable.

Premièrement, le filtrage côté hôte est très incohérent d’un éditeur à l’autre. Pour la même requête d’envoi d’e-mail contenant un identifiant, Claude Desktop affichait un ASR de 95 % contre 50 % pour ChatGPT (intervalles de confiance de Wilson à 95 % disjoints). ChatGPT avait tendance à refuser purement et simplement, ou à remplacer les identifiants par [REDACTED] avant transmission ; la même requête passait ailleurs sans encombre. « Est-ce sûr ? » n’a pas de réponse transposable : tout dépend de l’hôte utilisé.

Deuxièmement, c’est le canal, et non la technique, qui détermine le succès. Les attaques par description (C1) ne fonctionnaient de manière fiable que sur la substitution d’URL, tandis que les attaques par réponse (C2) — charges cachées dans ce que l’outil renvoie à l’exécution — réussissaient sur les trois scénarios LLM-actifs avec un ASR ≥ 85 %. La sortie d’outil au runtime est la surface sous-protégée, alors que l’outillage scrute encore surtout la description.

Troisièmement, et c’est le plus préoccupant en pratique : les attaques réussies ne sont presque jamais signalées à l’utilisateur. Le SRR était de 0 % pour toutes les attaques LLM-passives et la plupart des configurations LLM-actives. La seule exception : Claude signalait la charge insérée dans 100 % des essais réussis d’augmentation de code par réponse — preuve que la transparence est atteignable, mais pas encore systématique.

Défenses

Aucun contrôle unique ne couvre cette surface ; l’article plaide pour une posture en couches, chacune répondant à l’une des catégories ci-dessus.

• Le filtrage côté hôte avant invocation est la seule ligne de défense contre l’exfiltration LLM-passive. Retirez ou masquez les secrets (identifiants, jetons, données personnelles) des arguments avant tout envoi à un outil distant, et privilégiez un refus par défaut des données sortantes.
• L’audit des réponses au niveau du LLM est ce qui arrête le canal par réponse à fort ASR. Traitez les réponses d’outil comme des entrées non fiables — pas seulement les descriptions — et validez le contenu renvoyé par rapport à la requête réelle de l’utilisateur avant de le relayer.
• La transparence des sorties visibles par l’utilisateur est le filet de sécurité transversal. Exposez quel outil a été exécuté, quelles données il a reçues, et toute modification apportée par le modèle à sa réponse, pour qu’un succès silencieux (SRR 0 %) cesse de l’être.
• Côté exploitation : traitez les serveurs MCP distants comme du code tiers entrant dans votre périmètre de confiance. Épinglez et auditez les serveurs au lieu d’installer par URL, surveillez les changements « rug-pull » du mainteneur, et préférez des registres vérifiés aux agrégateurs ouverts.

Ces mesures rejoignent les recommandations en couches issues des benchmarks MCP comme MCPTox et des panoramas d’écosystème plus larges comme Beyond the Protocol.

Statut

Il s’agit de recherche académique publiée qui évalue des hôtes commerciaux tels que déployés, pas d’un CVE mono-éditeur. Les comportements sont caractéristiques du MCP distant en tant que modèle de conception, plutôt que d’un bug corrigeable ; les mitigations ci-dessus sont donc architecturales. Dates clés : MCP introduit fin 2024 ; incident Postmark en septembre 2025 ; article soumis le 27 avril 2026 et publié le 21 mai 2026. Le comportement de filtrage par plateforme peut évoluer à mesure que les éditeurs mettent à jour leurs hôtes — la leçon durable est la disparité entre plateformes.