Les assistants de codage capables d’appeler des outils externes peuvent, dans certains scénarios, devenir une porte d’entrée pour l’exfiltration de données. Selon la divulgation d’un laboratoire de recherche, un serveur malveillant branché via le Model Context Protocol (MCP) peut faire « migrer » des secrets (clés SSH, variables d’environnement, code source, données clients) sans jamais envoyer une instruction manifestement dangereuse.
La technique porte le nom de GhostSplice MCP. Son idée centrale : diviser la demande en fragments qui paraissent anodins, puis les faire se recoller par l’agent au fil des échanges. Résultat : même quand l’assistant refuse une version grossière du vol, il peut encore être amené à recomposer la chaîne malveillante.
Pourquoi les serveurs MCP changent la surface d’attaque
Le MCP est une norme ouverte qui permet à un assistant IA d’utiliser des outils connectés à l’extérieur. Concrètement, des serveurs MCP peuvent fournir des descriptions d’outils, des résultats, voire déclencher certains échantillonnages selon la configuration.
Le point sensible ne réside pas seulement dans la présence d’outils externes, mais dans la manière dont l’agent intègre ce qu’il reçoit. Une implémentation peut conserver des limites structurelles entre la description d’un outil et le résultat qu’il renvoie, mais cela ne suffit pas toujours à empêcher une recomposition malveillante dans le contexte de travail.
Autrement dit : même si chaque fragment pris séparément semble « inoffensif », l’ensemble peut mener à un exfiltration.
GhostSplice MCP : le principe de la fragmentation
GhostSplice MCP exploite le fait qu’un agent de codage travaille avec des informations provenant de plusieurs sources au sein d’un même contexte. L’attaque consiste à placer différentes parties d’une demande dans des canaux déjà utilisés par l’assistant.
Le mécanisme rapporté par l’équipe de recherche implique notamment que :
- un fragment se retrouve dans la description d’un outil ;
- un autre fragment se retrouve dans un résultat de cet outil ;
- les deux fragments sont ensuite recollés par l’agent pour former l’action finale.
Dans cette approche, il n’est pas nécessaire que l’intégralité de la demande malveillante figure dans un seul message. L’agent peut alors exécuter des étapes qui semblent routine, jusqu’à ce que la combinaison révèle l’objectif : récupérer des fichiers locaux sensibles et transmettre leur contenu.
Des fragments qui « ressemblent à du travail normal »
Les chercheurs soulignent que la forme de l’incitation compte. Une histoire de gouvernance élaborée ou un récit complexe peut piéger l’agent en donnant de quoi douter. À l’inverse, une mise en forme simple de type remplir le formulaire est plus difficile à contester.
Dans les tests décrits, un serveur annonce un outil qui paraît bénin, par exemple un contrôleur d’intégrité avec quelques champs neutres. Puis, plus tard, un résultat de scan fournit la correspondance manquante : les champs supposément ordinaires se retrouvent remplis par des contenus sensibles.
Dans l’exemple cité, le mapping pouvait pointer vers des éléments tels que :
- .ssh/id_rsa pour une clé SSH ;
- du code source propriétaire ;
- un fichier de type customers.csv ;
- un fichier .env pour des variables d’environnement.
Pris séparément, chaque morceau ne raconte pas l’histoire complète. Une fois assemblés, ils indiquent à l’agent quoi lire et quoi transmettre via l’outil annoncé.
Une barrière de sécurité peut varier selon le client
L’un des constats importants est que la même famille de modèles peut se comporter différemment selon le contexte d’exécution. Les chercheurs rapportent qu’un modèle peut refuser une tentative dans un client de codage, puis se laisser convaincre dans un autre, en fonction de la façon dont les contrôles de sécurité entourent les invocations d’outils.
Autrement dit, la défense ne se joue pas uniquement côté modèle. Elle dépend aussi de l’orchestration : comment les appels d’outils sont gérés, comment les sorties sont interprétées, et quels garde-fous permettent (ou empêchent) l’exécution.
Ce que les tests disent, et ce qu’ils ne prouvent pas
La divulgation fait état d’expériences en environnement contrôlé, dans des projets isolés et avec des identifiants factices. Les auteurs précisent aussi que des identifiants CVE devraient suivre un processus de divulgation coordonnée, tout en notant qu’aucun identifiant n’était listé au moment de la publication consultée.
Les résultats sont présentés sous forme de taux de conformité et varient fortement selon le scénario (version « en une seule pièce » contre variantes fractionnées) et selon l’outil de test.
Par exemple, dans certaines configurations, la conformité moyenne grimpe nettement quand la demande est scindée en deux fragments. La divulgation mentionne aussi des cas où un modèle atteignait une exécution complète dans un test fractionné, même si le score était nul dans le test où la demande apparaissait d’un seul tenant.
En revanche, les chiffres publiés doivent être interprétés avec prudence. Les chercheurs eux-mêmes signalent que des tableaux de résultats reflètent des configurations précises, et pas un comportement général garanti. Des signalements d’exfiltration partielle ou de redaction sélective sont aussi mentionnés pour certains scénarios.
Limites de l’attaque : ce n’est pas une intrusion « de l’extérieur »
GhostSplice MCP ne décrit pas une attaque qui « casse » n’importe quel agent à distance. Selon la divulgation, l’attaque suppose que le développeur a déjà connecté un serveur MCP contrôlé par l’attaquant, et que l’agent a déjà accès aux fichiers que l’attaque vise à lire.
Autrement dit, il s’agit surtout d’un risque d’intégration : si votre environnement fait confiance à des serveurs MCP non vérifiés, l’assistant peut devenir le vecteur qui assemble et exécute des étapes menant à la fuite.
Comment se défendre contre GhostSplice MCP
La défense proposée s’articule autour de deux principes : réduire les invocations non maîtrisées, et traiter toute sortie de serveur comme une donnée non fiable.
D’après les recommandations associées au MCP, un client devrait maintenir une validation humaine capable de refuser l’invocation d’outils. La spécification insiste également sur le fait de considérer comme non fiables les annotations venant de serveurs non de confiance.
Le conseil opérationnel de l’équipe de recherche va plus loin. L’idée est de :
- traiter le contenu renvoyé par le serveur comme des données, pas comme des instructions ;
- empêcher que des valeurs issues d’un résultat d’outil se retrouvent automatiquement utilisées comme arguments d’un autre outil, sans contrôle.
En pratique, cela revient à établir des garde-fous stricts sur la façon dont les sorties et entrées des outils circulent dans le pipeline. Si un résultat contient une valeur qui pourrait servir à désigner des fichiers ou à configurer des actions sensibles, le système doit exiger une vérification avant de laisser l’agent poursuivre.
Un précédent : quand la frontière de sécurité se fissure
GhostSplice MCP s’inscrit dans une série d’enseignements : la sécurité peut se jouer moins sur la « force » du modèle que sur la frontière que l’on construit autour de lui.
Les chercheurs relient leur technique à une divulgation antérieure portant sur un mécanisme différent, où une instruction cachée dans un artefact de projet pouvait pousser un agent à intégrer des secrets de manière détournée. Le fil conducteur reste le même : si le système laisse les informations provenant de sources non fiables influencer des décisions sensibles, un contournement peut apparaître.
Conclusion : sécuriser les intégrations, pas seulement les modèles
GhostSplice MCP montre comment un serveur MCP malveillant peut exploiter la façon dont un assistant de codage assemble des informations au fil des interactions. En fragmentant les éléments de la demande, l’attaque peut contourner des refus « évidents » et parvenir à l’exfiltration de secrets.
La réponse n’est pas uniquement de changer de modèle. Elle passe par une intégration plus stricte : validation humaine des invocations, confiance minimale envers les serveurs non vérifiés, et contrôle des flux de données entre sorties d’outils et arguments d’actions suivantes.
Source: https://thehackernews.com/2026/08/malicious-mcp-servers-can-split.html
