Un fichier .mcp.json suffit à détourner votre agent de code

Depuis un an, brancher un agent de code sur ses outils internes est devenu une habitude de travail. On connecte l'assistant à un dépôt Git, à une base de données, parfois à une instance Odoo via un connecteur. Le protocole qui rend ces branchements possibles porte un nom : MCP¹. Il est pratique. Il est aussi en train de devenir la surface d'attaque la plus mal comprise de nos chaînes de développement. Une faille corrigée en juin explique pourquoi.

La faille qui part d'un simple clone

En juin 2026, les chercheurs de Wiz ont divulgué CVE-2026-12957, notée 8,5 sur l'échelle CVSS². La cible : Amazon Q Developer, l'assistant de code d'AWS. Le mécanisme tient en une phrase. Amazon Q lisait un fichier de configuration, .amazonq/mcp.json, présent dans le dépôt ouvert, puis lançait automatiquement les serveurs MCP qu'il déclarait. Ces serveurs sont des processus locaux qui héritent de l'environnement du développeur : clés AWS, jetons de CLI cloud, secrets d'API, socket de l'agent SSH. Autrement dit, un fichier déposé dans un dépôt que vous veniez de cloner pouvait exécuter du code arbitraire avec votre session cloud active attachée. Du git clone à la compromission cloud, sans un clic supplémentaire.

AWS a corrigé le défaut dans la version 1.65.0 des Language Servers, et son bulletin recommande de passer directement à la 1.69.0. Amazon Q signale désormais un serveur MCP non approuvé et laisse le développeur refuser la commande avant qu'elle ne s'exécute.

Pas un accident isolé

La tentation serait de classer l'affaire comme le bug d'un seul fournisseur. Les faits disent autre chose. Selon Wiz, des vulnérabilités comparables ont touché au moins trois produits de trois éditeurs différents. Claude Code et Cursor exposaient tous deux une configuration MCP au niveau du projet qui menait à l'exécution de commandes, et Windsurf aboutissait au même résultat par un autre chemin. Le point commun n'est pas un éditeur négligent en particulier, mais le modèle de confiance de MCP lui-même, qui traite le contenu d'un espace de travail comme légitime par défaut.

Un protocole pensé pour la commodité, pas pour la méfiance

Le problème dépasse l'auto-exécution. La spécification d'autorisation de MCP décrit bien un cadre OAuth 2.1, mais elle marque l'authentification comme optionnelle. Le résultat est concret : un scan d'Internet mené en juillet 2025 a recensé au moins 1 862 instances MCP publiquement accessibles répondant à des requêtes non authentifiées. La Cloud Security Alliance, s'appuyant sur des travaux d'OX Security divulgués en avril 2026, évoque un défaut systémique touchant environ 200 000 instances vulnérables. L'analyse de plus de 10 000 serveurs réels a par ailleurs montré des fuites d'identifiants, de clés d'API et de données personnelles à un taux dépassant 10 %. En juillet 2026, la NSA a publié ses propres recommandations de durcissement pour MCP, signe que le sujet a quitté le cercle des chercheurs.

Une autre catégorie de risque mérite d'être nommée : le tool poisoning³. Le modèle lit le nom, la description et les paramètres d'un outil pour décider quand l'appeler. Un attaquant qui contrôle ces métadonnées, via un serveur malveillant ou une entrée de registre compromise, peut rédiger des descriptions qui poussent l'agent vers des actions que personne n'a demandées.

Ce que cela implique pour une PME sur Odoo

Une PME qui outille ses développeurs avec un agent de code et quelques connecteurs se retrouve, sans toujours le savoir, à faire tourner des processus tiers avec les droits de la personne connectée. Si l'un de ces connecteurs touche votre instance Odoo, votre facturation ou votre base clients, le périmètre d'un incident n'est plus le poste du développeur : c'est votre ERP.

La bonne posture tient en quelques réflexes. Il faut traiter chaque serveur MCP comme un tiers non fiable, au même titre qu'une dépendance externe. Il faut refuser le lancement automatique de serveurs déclarés dans un dépôt cloné. Il faut séparer les identifiants, car l'agent de code ne devrait jamais hériter d'une session cloud de production. Enfin, épingler les versions des outils et suivre leurs bulletins évite de rester exposé après un correctif. Ces gestes ne sont pas nouveaux. Ils rejoignent un constat que nous faisions déjà à propos du code généré, qui passe la revue fonctionnelle mais rarement la revue de sécurité.

Notre lecture

Nous regardons ces connecteurs comme une extension du principe de moindre privilège, pas comme un simple gain de productivité. La CVE-2026-12957 est corrigée, c'est un fait acquis. La surface qu'elle a révélée, elle, reste ouverte tant que les équipes branchent des serveurs MCP sans se demander avec quels droits ils tournent. Pour une PME, la règle pratique est facile à énoncer et exigeante à tenir : un agent de code ne mérite que les accès dont il a besoin pour la tâche du jour, et pas un de plus. Avant d'ajouter un connecteur à votre chaîne, posez la question que beaucoup d'incidents de 2026 auraient évitée. Si ce serveur se retournait contre vous, qu'atteindrait-il ?

Sources

• The Register, « Amazon Q flaw let booby-trapped Git repos execute code, swipe cloud creds » : https://www.theregister.com/cyber-crime/2026/06/26/amazon-q-flaw-let-booby-trapped-git-repos-execute-code-swipe-cloud-creds/
• Wiz Blog, « Amazon Q Vulnerability: Compromise via MCP Auto-Execution » : https://www.wiz.io/blog/amazon-q-vulnerability
• The Hacker News, « Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs » : https://thehackernews.com/2026/06/amazon-q-developer-flaw-could-let.html
• Cloud Security Alliance, « MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure » : https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled/
• Adversa AI, « Top MCP security resources & CVEs July 2026 » : https://adversa.ai/blog/top-mcp-security-resources-july-2026/
• NSA, « Model Context Protocol (MCP) Security » : https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf