La réponse en bref
Le MCP Gateway ContextForge d'IBM présente une faille d'exécution de code à distance de gravité maximale — CVE-2026-53710, CVSS 10.0 — qui permet à un attaquant non authentifié de s'évader de sa sandbox Python et d'exécuter des commandes OS. Le python_sandbox_server de la passerelle exécute du code Python non fiable dans RestrictedPython mais ne protège pas l'accès aux attributs ; en abusant du builtin getattr, un attaquant remonte des objets autorisés vers des objets dangereux comme subprocess.Popen et exécute des commandes shell sur l'hôte. Toutes les versions antérieures à 1.0.2 sont concernées, et le correctif est en 1.0.2. Parce qu'un gateway MCP arbitre l'accès d'un modèle de langage aux outils, aux données et aux identifiants, l'exécution de code à cet endroit est un point d'appui vers tout ce qui se trouve en aval. Si vous exploitez cette passerelle — et qu'elle fait partie de votre infrastructure d'agents IA —, mettez-la à jour maintenant.
Aucun exploit public n'a été signalé à la date de divulgation, le 15 septembre 2026. C'est à la fois la bonne nouvelle et l'échéance : un bug distant, pré-authentification, avec exécution complète de commandes, est exactement ce qui est militarisé rapidement dès qu'une preuve de concept circule. Patchez en 1.0.2 en changement d'urgence, isolez la passerelle des réseaux non fiables et faites tourner tous les identifiants qu'elle détient pour les outils en aval.
Qu'est-ce que la CVE-2026-53710 ?
Le Model Context Protocol (MCP) est devenu le câblage commun des agents IA : il standardise la façon dont un modèle de langage découvre et appelle des outils, des sources de données et des API externes. Une passerelle MCP est le middleware placé devant ces connexions — elle route les requêtes, applique la politique et détient les identifiants dont chaque outil a besoin. Le ContextForge MCP Gateway d'IBM est une implémentation open source largement utilisée, publiée sous le paquet mcp-contextforge-gateway et développée dans le projet public IBM/mcp-context-forge.
Le 15 septembre 2026, une vulnérabilité de gravité maximale dans cette passerelle a été divulguée sous la référence CVE-2026-53710, notée CVSS 10.0. Elle réside dans le python_sandbox_server de la passerelle — un composant qui exécute du code Python fourni par l'utilisateur ou le modèle dans une sandbox RestrictedPython, dont tout l'objet est de laisser tourner du code potentiellement non fiable sans toucher à l'hôte. Le défaut : la sandbox n'applique pas les protections nécessaires sur l'accès aux attributs. Un attaquant peut utiliser le builtin getattr pour atteindre des objets et des méthodes que la sandbox était censée garder hors d'atteinte — en fin de compte subprocess.Popen — et de là exécuter des commandes système arbitraires. Aucune connexion n'est requise, et le résultat est le contrôle total de l'hôte de la passerelle. Quiconque exploite ce composant devrait traiter son durcissement comme un travail central d'infrastructure d'agents IA.
Toutes les versions du ContextForge MCP Gateway antérieures à 1.0.2 sont concernées ; le correctif a atterri en 1.0.2, qui rétablit les restrictions d'accès aux attributs manquantes. À la date de divulgation, il n'existe aucun exploit de preuve de concept public ni exploitation confirmée dans la nature — mais avec un chemin distant et non authentifié menant directement à l'exécution de commandes, cet écart est un compte à rebours, pas un réconfort.
Comment fonctionne l'évasion de sandbox
Les sandboxes au niveau du langage comme RestrictedPython fonctionnent en compilant le code contre un ensemble limité de builtins autorisés et en bloquant les opérations manifestement dangereuses — imports, accès direct aux attributs dunder, et autres. La sécurité dépend du contrôle par la sandbox de tout chemin par lequel le code peut atteindre un objet puissant. L'accès aux attributs est l'un de ces chemins, et il est notoirement difficile à verrouiller complètement, car Python permet de récupérer des attributs de manière dynamique.
C'est cette fissure qu'exploite la CVE-2026-53710. Le builtin getattr résout un attribut par son nom à l'exécution, de sorte que même si la syntaxe littérale pour atteindre un attribut dangereux est bloquée, getattr(obj, "name") peut le récupérer via une recherche par chaîne que la sandbox n'intercepte pas. En enchaînant ces recherches, un attaquant traverse d'un objet de départ anodin vers les internes de modules et enfin vers subprocess.Popen, qui lance un vrai processus OS. Parce que le python_sandbox_server expose cela sur le réseau sans authentification, toute la séquence s'exécute à partir d'une seule requête non authentifiée — et elle s'exécute avec les privilèges du processus de la passerelle.
Ce qui en fait une CVSS 10.0 plutôt qu'un bug simplement sérieux, c'est la combinaison et l'emplacement. C'est distant, sans identifiant requis et sans interaction utilisateur, donc trivial à automatiser à grande échelle. Et cela atterrit sur le composant même dont le rôle est d'exécuter en sécurité du code non fiable : quand une sandbox casse, l'hypothèse qui rendait acceptable l'exécution de ce code — « c'est confiné » — s'effondre. Une passerelle n'est pas non plus un nœud feuille : elle détient les clés et les connexions vers tout ce à quoi l'agent était câblé.
Ce que cela signifie pour les équipes logicielles en France
Retirez le numéro de CVE et trois leçons durables demeurent. Premièrement, votre gateway MCP est une infrastructure de production, pas du code de collage. Les équipes en montent un pendant un proof-of-concept d'agent, y câblent une douzaine d'outils et leurs identifiants, et ne lui donnent jamais le modèle de menace qu'elles donneraient à une API publique. Pourtant, il se situe entre le modèle et vos systèmes et détient les identifiants des deux. Il mérite la même urgence de correctif, la même segmentation réseau et la même authentification que votre périmètre.
Deuxièmement, une sandbox de langage n'est pas une frontière de sécurité sur laquelle s'appuyer seule. RestrictedPython et ses pairs sont utiles, mais leur histoire est un filet continu d'évasions exactement comme celle-ci — astuces d'accès aux attributs, redérivation de builtins, traversée de dunder. Si vous devez exécuter du code non fiable ou généré par un modèle, enveloppez la sandbox de langage dans une véritable isolation au niveau OS : un conteneur verrouillé, des filtres seccomp, gVisor ou une microVM, sans réseau ni identifiants ambiants. La défense en profondeur signifie qu'un seul bug de sandbox ne devient pas une compromission de l'hôte.
Ce que cela signifie pour le marché français. En France, les grands comptes et les scale-up ont poussé les agents IA en production sur fond de souveraineté numérique et de « cloud de confiance ». Le point aveugle récurrent y est le même : la passerelle MCP montée pendant un POC reste en service sans être traitée comme un actif de production, alors qu'elle concentre identifiants et accès réseau.
Troisièmement, l'infrastructure d'agents concentre le rayon d'impact, donc le moindre privilège est le contrôle qui paie. L'exécution de code sur une passerelle est dangereuse en proportion de ce que la passerelle peut atteindre. Si elle tourne avec des identifiants larges et un accès réseau à plat vers vos bases de données et API internes, un bug est une compromission de tout ; si chaque connecteur d'outil a des identifiants au périmètre étroit et rotatifs et que la passerelle est segmentée, le même bug est confiné. Pour les équipes en France, une RCE non authentifiée sur un système arbitrant l'accès à des données personnelles ou financières engage le RGPD (sous le contrôle de la CNIL), la directive NIS2 telle que transposée en droit français (dont l'ANSSI est l'autorité de référence) et, pour les entités financières, les attentes de DORA en matière de remédiation rapide et de risque lié à la chaîne d'approvisionnement TIC. Corriger en quelques heures — et pouvoir le prouver — est l'investissement au plus fort effet de levier.
Que faire maintenant
- Mettre à jour vers 1.0.2 immédiatement. Faites passer tout ContextForge MCP Gateway sur une version antérieure à 1.0.2 en 1.0.2 ou ultérieure — qu'il soit auto-hébergé depuis les sources ou installé via le paquet
mcp-contextforge-gateway. Traitez-le comme un changement d'urgence, non comme de la maintenance de routine. - Isoler la passerelle si vous ne pouvez pas patcher tout de suite. Restreignez l'accès réseau pour que seuls des appelants de confiance puissent l'atteindre, et désactivez la fonction d'exécution de code du
python_sandbox_serversi vous ne vous en servez pas. Supprimer l'accessibilité non fiable neutralise le chemin distant. - Faire tourner les identifiants qu'elle arbitre. La passerelle détient les secrets des outils et API en aval que vos agents appellent. Si elle était atteignable depuis des réseaux non fiables, présumez l'exposition et faites tourner ces identifiants d'outils, jetons et clés — patcher ne dé-fuit pas ce qui a peut-être déjà disparu.
- Ajouter une isolation au niveau OS autour du code non fiable. Ne laissez pas une sandbox de langage être la seule chose entre le code généré par le modèle et votre hôte. Exécutez le serveur de sandbox dans un conteneur durci ou une microVM avec seccomp, des capacités retirées et sans identifiants ni réseau ambiants.
- Intégrer l'infrastructure d'agents et de MCP au périmètre de test. Les passerelles, les connecteurs d'outils et les identifiants qui les sous-tendent sont régulièrement laissés hors des revues de sécurité. Incluez-les dans votre prochain test d'intrusion et audit de sécurité, et inventoriez quels systèmes internes chaque connecteur peut réellement atteindre.
Questions fréquentes
Qu'est-ce que la CVE-2026-53710 dans le gateway MCP d'IBM ?
C'est une vulnérabilité de gravité maximale (CVSS 10.0) dans le MCP Gateway ContextForge d'IBM, la passerelle Model Context Protocol open source livrée sous mcp-contextforge-gateway. Son python_sandbox_server exécute du code dans une sandbox RestrictedPython mais ne protège pas l'accès aux attributs. En abusant du builtin getattr, un attaquant atteint des fonctions comme subprocess.Popen et exécute des commandes OS sans authentification, prenant le contrôle total de l'hôte de la passerelle.
Quelles versions sont concernées et quel est le correctif ?
Toutes les versions antérieures à 1.0.2 sont concernées ; le correctif est livré en 1.0.2, qui rétablit les restrictions d'accès aux attributs manquantes. Mettez à jour toute passerelle — auto-hébergée ou installée via le paquet pip — en 1.0.2 ou ultérieure immédiatement. Si vous ne pouvez pas mettre à jour tout de suite, désactivez ou isolez au niveau réseau la fonction python_sandbox_server et restreignez qui peut atteindre la passerelle.
Est-elle exploitée dans la nature ?
À la date de divulgation, le 15 septembre 2026, aucun exploit public ni exploitation confirmée dans la nature n'a été signalé. Vu le profil — distant, non authentifié, exécution complète de commandes — ce n'est pas une raison pour attendre. Les bugs de ce type sont militarisés rapidement dès qu'une preuve de concept apparaît, donc patchez de manière préventive.
Pourquoi une évasion de sandbox dans une passerelle est-elle si grave ?
Un gateway MCP arbitre l'accès d'un modèle aux outils, aux données et aux API internes, et détient les identifiants de ces systèmes. L'exécution de code sur la passerelle est donc un point d'appui vers tout ce qu'elle peut atteindre — pas une compromission d'hôte isolée. La sandbox existait pour confiner en sécurité du code non fiable généré par un modèle ; quand elle échoue, cette garantie de confinement disparaît.
Comment sécuriser l'infrastructure MCP et d'agents sur le long terme ?
Traitez la passerelle comme une infrastructure de production : patchez vite, placez-la derrière une authentification, gardez-la hors des réseaux non fiables et exploitez-la avec des identifiants au moindre privilège, rotatifs par outil. Ne vous reposez pas sur une sandbox de langage seule — ajoutez une isolation au niveau OS comme des conteneurs, seccomp ou des microVM autour du code non fiable. Et incluez la passerelle et ses connecteurs dans des tests de sécurité réguliers, car ils sont souvent hors périmètre.
Sources
GitHub Advisory Database — GHSA-xm98-3vcf-fph7: RestrictedPython sandbox bypass via getattr in python_sandbox_server (CVE-2026-53710)
NVD — CVE-2026-53710
IBM — ContextForge MCP Gateway security advisories