1 min de lecture
Un serveur MCP malveillant n’a plus besoin d’envoyer une instruction ouvertement dangereuse pour voler vos clés SSH, votre .env ou votre code source. Il lui suffit de la découper en morceaux anodins, disséminés dans les canaux que votre agent de codage utilise déjà, pour qu’il la recolle tout seul.
Personne n’a besoin de convaincre l’agent de faire quelque chose de mal
On fragmente la requête malveillante en morceaux qui, lus séparément, ne ressemblent à rien de suspect ; on les dissémine dans des canaux que l’agent utilise déjà (description d’un outil MCP, résultat d’un outil, parfois du sampling initié par le serveur lui-même) ; et on laisse l’agent recombiner tout ça dans son propre contexte de travail. Le MCP maintient pourtant des frontières structurées entre outils et résultats. Les tests d’ASSET montrent que ça ne change rien du tout.
Lu séparément, aucun fragment ne contient le vol. Lu ensemble par l’agent, c’est une exfiltration complète.
En découpant la requête malveillante en deux morceaux plutôt qu’un seul, le taux de conformité moyen (comprendre : l’agent exécute l’exfiltration) passe de 42% à 82% sur les modèles testés via API. GPT-4o, Gemini 2.0 Flash et Llama 3.3 70B passent de 0% en requête monolithique à 100% dès qu’on scinde la requête en deux.
Dans la version longue, je reprends le mécanisme complet (outil anodin integrity_checker, mapping alpha/beta/gamma/delta, variante à trois canaux), le tableau des 15 modèles testés, l’analyse STRIDE, l’impact et les mitigations à mettre en place côté client MCP.
L'analyse détaillée part d'abord aux abonnés payants de ma newsletter Substack, avant d'être publiée intégralement ici.
Au Menu de la version abonnés, vous retrouvez la suite :
- le tableau complet des 15 modèles testés (avec les écarts qui font mal, 0% à 100% pour certains rien qu'en scindant la requête en deux) ;
- l'analyse STRIDE et l'impact détaillés ;
- les 5 mitigations concrètes à mettre en place côté client MCP ;
- un aperçu du contenu premium sur la validation des sorties d'outils et la détection de reconstruction d'instruction fragmentée ;
- et la sketchnote du PandaRedacteur résumant tout cela en anglais.
Articles lies
OVHcloud CLI et LiteLLM : à deux jours d'écart, les mêmes contrôles absents
Analyse comparée des compromissions OVHcloud CLI (19/10/2026) et LiteLLM 1.107.0 (21/10/2026) : chaîne d'attaque, contrôles SLSA, releases immuable...
28/10/2026LiteLLM au KEV : votre gateway IA est un plan de contrôle, traitez-la comme votre IAM
Analyse de la CVE-2026-59822 (LiteLLM, contournement d'authentification sur l'endpoint MCP Streamable HTTP, CVSS 4.0 8.8, CISA KEV le 2 septembre 2...
27/10/2026Poisoning the Watchtower : quand l'agent SOC prend vos logs pour des ordres
Analyse de la log-substrate prompt injection contre les agents SOC : taxonomie de Poisoning the Watchtower (arXiv 2605.24421), résultats de LogInje...
26/10/2026SlugFest : un nom de repo n'est pas une identité, de npm à vos rôles IAM
Analyse de SlugFest (Bloom Security, 13 octobre 2026) : le Trusted Publishing npm liait un package au nom d'un repo GitHub et non à son identifiant...
23/10/2026MCP TypeScript SDK : c'est le serveur MCP qui choisissait à qui envoyer vos secrets OAuth
Analyse de la CVE-2026-104850 dans le SDK TypeScript officiel du Model Context Protocol : mécanisme de confusion de serveur d'autorisation, issuer ...
20/10/2026