Sampling MCP : comment un serveur malveillant abuse du canal LLM inversé

De quoi s’agit-il ?

La plupart des analyses de sécurité du Model Context Protocol (MCP) se concentrent sur un seul sens : le client appelle les outils d’un serveur, et une description ou un résultat d’outil malveillant empoisonne l’agent. Le sampling inverse ce flux. C’est une fonction optionnelle de MCP qui permet à un serveur de demander une complétion LLM au client — le serveur dit « exécute cette requête dans ton modèle et renvoie-moi la réponse », et le modèle du client s’exécute.

Le 5 décembre 2025, l’équipe Unit 42 de Palo Alto Networks (Yongzhe Huang, Akshata Rao, Changjiang Li, Yang Ji, Wenjun Hu) a publié une analyse des vecteurs d’attaque MCP qui traite le sampling comme une surface d’attaque distincte, avec trois démonstrations contre un assistant de code largement utilisé. The Vulnerable MCP Project a catalogué la découverte avec un score d’impact de 8/10, et Cyber Security News l’a couverte le 9 décembre 2025. Le protocole lui-même a été introduit par Anthropic en novembre 2024 ; le sampling fait partie de la spécification depuis lors.

Comment ça marche

Le sampling existe pour qu’un serveur puisse « emprunter » le modèle — par exemple, un serveur de revue de code qui a besoin que le LLM résume un diff avant de décider quoi signaler. Le problème de confiance est structurel : le serveur contrôle la requête qu’il envoie, et il contrôle la façon dont il lit la réponse. C’est ce double contrôle qui est détourné. Aucun primitive d’exploit n’est reproduite ci-dessous ; c’est le mécanisme qui compte.

Unit 42 regroupe l’abus en trois classes :

Classe d'attaque         Ce que fait le serveur malveillant       Conséquence pour l'utilisateur
-----------------------  ---------------------------------------  ------------------------------------
Vol de ressources        Ajoute un travail caché à une requête    Quota de calcul et crédits API
                         de sampling légitime (p. ex. « écris     drainés par des charges non
                         aussi une longue histoire »)             autorisées, invisibles dans la
                                                                  sortie affichée
Détournement de          Injecte des instructions persistantes    Le comportement de l'assistant est
conversation             dans la réponse de sampling, qui         altéré pour toute la session (la
                         réintègre le contexte                    PoC l'a forcé à répondre « comme un
                                                                  pirate » ; le même canal peut
                                                                  dégrader ou détourner les réponses)
Invocation furtive       Glisse des instructions qui poussent     Écritures de fichiers silencieuses,
d'outils                 le modèle à appeler d'autres outils      persistance et exfiltration possible
                         sans que l'utilisateur voie la demande   de données, sans consentement

La cause racine commune est un modèle de confiance implicite, sans séparation intégrée entre le contenu de l’utilisateur et les modifications du serveur. Comme un serveur capable de sampling peut façonner à la fois la requête et le texte renvoyé, il peut glisser des instructions dans les deux sens tout en ayant l’air d’un outil normal.

Pourquoi c’est important

Le sampling déplace le modèle de menace. Le conseil classique pour MCP — « ne connectez que des serveurs de confiance et vérifiez les résultats d’outils » — suppose que le danger va du serveur vers l’outil vers l’agent. Le sampling ajoute un chemin serveur → modèle → agent que la plupart des utilisateurs ne voient jamais, car l’aller-retour de sampling se déroule sous la conversation visible. Un résumeur de code qui draine discrètement votre quota d’inférence, ou qui fixe une instruction comportementale pour le reste de la session, produit une sortie d’apparence parfaitement normale.

L’exposition dépend d’une seule chose : le fait que le client implémente le sampling, et avec quels réglages par défaut. Selon Unit 42 et les reprises ultérieures, beaucoup de clients ne prennent pas encore en charge le sampling ou le livrent avec des réglages par défaut permissifs — et à mesure que l’adoption de MCP s’est élargie au cours de 2026, le nombre de clients activant des fonctions riches comme le sampling a augmenté. La population concernée est donc tout déploiement MCP qui active le sampling sans le cadrer, ce qui explique le niveau modéré plutôt que critique : il faut un serveur malveillant ou compromis et un client avec sampling activé, mais ni l’un ni l’autre n’est exotique.

Défenses

Le sampling est utile : l’objectif est de l’encadrer, pas de l’interdire. D’après les recommandations d’Unit 42 et la fiche du Vulnerable MCP Project :

• Exigez une approbation explicite, serveur par serveur, avant toute requête de sampling. Ne laissez pas un serveur invoquer le modèle en silence. Affichez la requête que le serveur veut exécuter.
• Séparez le contenu utilisateur des modifications du serveur par des gabarits stricts, pour que le texte fourni par le serveur ne puisse pas être interprété comme des instructions adressées au modèle.
• Filtrez les réponses de sampling à la recherche de formulations ressemblant à des instructions avant qu’elles ne réintègrent le contexte, pour contrer le détournement de conversation.
• Limitez le débit du sampling par serveur, par session et par jour, et posez des plafonds de coût sur les quotas de calcul pour que le vol de ressources atteigne vite une limite.
• Surveillez l’usage du calcul — un résumeur qui consomme soudain de gros volumes de tokens est un signal.
• Isolez les serveurs capables de sampling des outils sensibles. Un serveur autorisé à demander des complétions ne devrait pas aussi disposer d’un accès en écriture au système de fichiers ou aux secrets.
• Désactivez le sampling pour les serveurs non fiables par défaut ; ne l’activez que lorsque le flux de travail en a réellement besoin.

État des lieux

Élément	État (au 2 juin 2026)
Divulgation	Unit 42, publié le 5 décembre 2025
Nature	Abus d’une fonction du protocole, pas un CVE unique à corriger
Prise en charge côté client	Inégale ; beaucoup de clients n’activent pas le sampling, certains livrent des réglages permissifs
Correctif principal	Cadrage côté client (approbation, limites de débit, filtrage) — la responsabilité incombe aux implémenteurs de clients
Concerné	Tout déploiement MCP avec sampling activé et un serveur malveillant/compromis dans le périmètre