Détournement de prompt MCP : la faille qui fragilise les assistants IA connectés

Les assistants d’intelligence artificielle ne se contentent plus de répondre à des questions : ils consultent des bases de données, interrogent des services en ligne, accèdent à des fichiers locaux et accompagnent des tâches de développement. Cette capacité d’action rend les outils bien plus utiles, mais elle étend aussi leur surface d’attaque. La vulnérabilité CVE-2025-6515, relevée dans l’implémentation oatpp-mcp, illustre un risque concret : détourner la conversation technique entre une IA et un outil auquel elle est reliée.

L’expression « détournement de prompt MCP » peut laisser croire qu’il suffirait de tromper un modèle de langage par une instruction habilement formulée. Le problème décrit ici est différent. Il concerne le canal de communication et la gestion des sessions utilisés autour de l’IA. Autrement dit, ce n’est pas nécessairement l’intelligence du modèle qui est prise en défaut, mais l’infrastructure qui lui fournit des données et lui renvoie des résultats.

MCP, le protocole qui relie une IA à son environnement

Un grand modèle de langage sait produire du texte à partir des informations contenues dans son contexte et de son entraînement. En revanche, il ne connaît pas spontanément l’état d’un dossier de l’entreprise, le contenu d’un dépôt de code ou le résultat d’une requête dans un logiciel métier. Pour obtenir ces informations, il doit être relié à des outils externes.

C’est l’objectif du Model Context Protocol, plus souvent désigné par son sigle MCP. Lancé par Anthropic, ce protocole propose une manière standardisée de faire dialoguer une application d’IA, souvent appelée client, avec des serveurs qui exposent des outils, des ressources ou des instructions. Dans un environnement de travail, une même interface conversationnelle peut ainsi demander à un service connecté de chercher un document, de lire une information ou d’exécuter une opération autorisée.

Cette architecture répond à une attente légitime des entreprises : éviter que chaque assistant et chaque logiciel utilisent leur propre connecteur. Mais la standardisation ne supprime pas le besoin de sécurité. Elle déplace une partie de la confiance vers les serveurs MCP, les bibliothèques qui les implémentent, les mécanismes d’authentification et les applications clientes qui interprètent les réponses.

Où se situe la faille CVE-2025-6515 ?

Le problème signalé dans oatpp-mcp se situe dans la couche de transport des échanges. Cette implémentation en C++ relie différents programmes au standard MCP et s’appuie notamment sur les événements envoyés par le serveur, appelés SSE, pour acheminer des informations vers le client.

Dans une session normale, un utilisateur se connecte et le serveur attribue un identifiant qui doit permettre de reconnaître cette session par la suite. Cet identifiant est un élément de sécurité : il ne doit pas être devinable, ni réutilisable par erreur, ni facilement confondu avec celui d’une autre connexion.

Or le mécanisme pointé dans CVE-2025-6515 utiliserait une adresse mémoire comme identifiant de session. Le choix est problématique. Une adresse mémoire n’est pas conçue comme un jeton secret : les ordinateurs peuvent réemployer des zones de mémoire à mesure que des objets sont créés puis supprimés. Un identifiant construit de cette façon risque donc de devenir prévisible ou de réapparaître.

Les spécialistes à l’origine de l’alerte décrivent un scénario dans lequel un attaquant multiplie les ouvertures et fermetures de sessions afin de repérer des identifiants valides ou anticipables. Il peut ensuite envoyer des requêtes destinées à être associées à une session réelle. Le serveur ne dispose alors pas toujours des éléments nécessaires pour distinguer le véritable utilisateur d’un acteur malveillant.

Le point décisif tient au résultat de cette confusion : la réponse nuisible est renvoyée dans l’environnement du client légitime. Si l’application cliente traite ce message comme une réponse digne de confiance, elle peut l’afficher à l’utilisateur ou le transmettre à l’assistant. C’est ce chaînage entre une faiblesse d’infrastructure et un système d’IA qui explique l’appellation de détournement de prompt.

Comment une réponse falsifiée peut influencer une IA

Dans l’exemple évoqué par les chercheurs, un programmeur demande à son assistant IA une bibliothèque Python permettant de traiter des images. Si un tiers parvient à injecter une réponse dans le bon flux de communication, l’assistant peut recevoir une recommandation frauduleuse à la place d’une réponse attendue.

Le risque est particulièrement sérieux dans le développement logiciel. Les assistants de code sont de plus en plus sollicités pour recommander des dépendances, générer des commandes ou expliquer la configuration d’un projet. Une bibliothèque malveillante ou un paquet contrefait introduit dans cette chaîne peut affecter bien plus qu’un seul poste de travail. C’est le principe d’une atteinte à la chaîne d’approvisionnement logicielle : compromettre un maillon réutilisé par de nombreux projets ou utilisateurs.

Il faut toutefois éviter tout raccourci. Une réponse injectée ne signifie pas automatiquement qu’un code malveillant sera exécuté. Entre une recommandation produite par un assistant et l’installation effective d’un composant, un développeur, une politique interne ou un outil de contrôle peut encore bloquer l’opération. Mais précisément, l’objectif de l’attaque est d’exploiter la confiance accordée à une interface IA intégrée au travail quotidien.

Pourquoi le client est aussi important que le serveur

La protection ne repose pas uniquement sur le serveur MCP. Une application cliente robuste doit être capable de vérifier que chaque événement reçu appartient bien à la session active et correspond au type de message attendu. Si elle accepte indistinctement plusieurs réponses, ou si elle se contente d’un identifiant trop simple, elle augmente les possibilités de confusion.

Les identifiants d’événements incrémentaux, par exemple une suite de numéros faciles à anticiper, posent un risque lorsqu’un attaquant peut tenter un grand nombre de valeurs. Cette famille de tentatives répétées est parfois qualifiée de « spraying ». Le remède de base est connu : les identifiants qui protègent une session doivent être produits par un générateur aléatoire robuste, adapté à un usage cryptographique.

Dans le cas d’un assistant IA, cette validation doit aller au-delà du seul identifiant. Le client a intérêt à contrôler, pour chaque message :

• sa provenance et son association à la connexion concernée ;
• son type et son format, afin de rejeter les événements inattendus ;
• les droits dont dispose le serveur ou l’outil qui formule la réponse ;
• l’action éventuelle qui découlera de la réponse, notamment lorsqu’elle porte sur un fichier, du code ou une donnée sensible.

Les mesures concrètes pour les équipes techniques

La première priorité est de vérifier si l’organisation utilise oatpp-mcp ou une architecture présentant des mécanismes comparables. Cet inventaire doit couvrir les projets de développement, les assistants internes, les outils de test et les connecteurs installés localement. L’adoption rapide de l’IA peut favoriser l’apparition de services non recensés, configurés par des équipes métiers ou des développeurs pour répondre à un besoin ponctuel.

Ensuite, les équipes doivent appliquer les correctifs de sécurité disponibles et maintenir les composants à jour. La présence d’un identifiant CVE permet justement de suivre une vulnérabilité identifiée publiquement et de l’intégrer aux processus habituels de gestion des risques.

La conception des sessions mérite un audit spécifique. Un serveur ne doit pas dériver ses jetons de session d’un élément prévisible tel qu’une adresse mémoire. Il doit générer des valeurs aléatoires robustes, uniques et difficiles à deviner. Les sessions doivent aussi être correctement isolées, expirées lorsque cela est nécessaire et invalidées à la déconnexion.

Enfin, les entreprises ont intérêt à appliquer une logique de zero-trust, ou confiance minimale. Ce principe consiste à ne pas considérer qu’un message est fiable du seul fait qu’il circule sur un réseau interne ou qu’il provient apparemment d’un service habituel. Chaque demande sensible doit être authentifiée, autorisée et vérifiée dans son contexte.

Un enjeu de gouvernance, pas seulement un bug technique

Les responsables de la sécurité des systèmes d’information et les directions techniques doivent traiter les connecteurs IA comme n’importe quelle autre brique exposée du système d’information. Cela implique d’identifier les données auxquelles un assistant peut accéder, les outils qu’il peut appeler et les conséquences d’une réponse erronée ou hostile.

Un assistant limité à la consultation de documents publics ne présente pas le même niveau de risque qu’un agent autorisé à lire du code privé, à modifier des tickets, à déclencher un déploiement ou à interroger une base de données. Le principe du moindre privilège est donc particulièrement pertinent : chaque outil connecté ne devrait disposer que des permissions strictement nécessaires à sa mission.

Les journaux d’activité sont également essentiels. Ils permettent de repérer des comportements inhabituels, comme des sessions anormalement nombreuses, des réponses incohérentes ou des demandes qui ne correspondent pas aux usages prévus. Pour être utiles, ces traces doivent être associées à une procédure claire : qui est alerté, quelles connexions sont suspendues et comment les équipes vérifient-elles l’intégrité des réponses échangées ?

Ce qu’il faut surveiller à mesure que MCP se diffuse

L’affaire CVE-2025-6515 montre que l’essor des assistants connectés crée une nouvelle catégorie de responsabilités. Les organisations ne doivent pas seulement évaluer la qualité des réponses d’un modèle de langage. Elles doivent aussi examiner avec la même rigueur les bibliothèques, serveurs, identifiants, autorisations et flux de données qui rendent ces réponses possibles.

À mesure que MCP est adopté, la qualité de ses implémentations deviendra aussi importante que les capacités des modèles eux-mêmes. Les projets qui privilégient une gestion robuste des sessions, des contrôles explicites côté client et des permissions limitées offriront un environnement plus résilient. Pour les entreprises, la bonne question n’est donc pas seulement « que peut faire notre assistant IA ? », mais aussi « à quelles données et à quels outils avons-nous choisi de le relier, et sous quelles garanties ? ».