CSRF du SDK Go MCP : une page web peut déclencher vos outils locaux (CVE-2026-33252)

De quoi s’agit-il ?

CVE-2026-33252 est une faille de falsification de requête intersite (CSRF, CWE-352) dans le SDK Go officiel du Model Context Protocol (github.com/modelcontextprotocol/go-sdk). L’avis de sécurité GitHub GHSA-89xv-2j6f-qhc8 a été publié le 19 mars 2026 et la CVE a été enregistrée dans la NVD le 24 mars 2026, avec une note de 7,1 (élevée). Le correctif est arrivé en v1.4.1 ; la vulnérabilité a été signalée par Lê Minh Quân.

En résumé : avant la v1.4.1, le transport Streamable HTTP du SDK acceptait des requêtes POST intersite générées par le navigateur sans valider l’en-tête Origin et sans exiger Content-Type: application/json. Sur un serveur MCP local exécuté sans autorisation — configuration très répandue en développement et pour les agents de bureau — n’importe quel site visité par l’utilisateur pouvait envoyer des requêtes MCP à ce serveur et potentiellement déclencher l’exécution d’outils. Nous le couvrons parce que c’est un exemple net et corrigé d’un problème systémique de 2026 : les serveurs MCP locaux considèrent l’interface loopback comme une frontière de confiance, et le navigateur la franchit silencieusement.

Comment ça marche

La politique de même origine du navigateur empêche normalement une page de evil.example de lire les réponses de 127.0.0.1. Mais les requêtes « simples » — celles dont le Content-Type figure dans la liste sûre CORS, comme text/plain — sont envoyées sans pré-vérification CORS. L’attaquant n’a jamais besoin de lire la réponse ; il lui suffit que la requête arrive.

La victime ouvre la page         ──►  fetch("http://127.0.0.1:<port>/mcp",
de l'attaquant (navigateur normal)     { method: "POST",
                                         headers: { "Content-Type": "text/plain" },
                                         body: <MCP JSON-RPC : tools/call ...> })

Serveur MCP local (avant 1.4.1) :
  - aucune vérif. d'Origin       ──►  requête acceptée
  - Content-Type non imposé      ──►  corps interprété comme message MCP
  - aucune autorisation requise  ──►  outil invoqué

Comme le serveur ne vérifiait pas la provenance, un POST intersite était indiscernable d’un client local légitime. L’impact est noté intégrité élevée, confidentialité nulle (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) : l’attaquant peut provoquer des actions (appels d’outils) mais ne peut pas lire directement la réponse à travers les origines. L’interaction utilisateur requise se résume à « visiter une page ». Aucun payload n’est reproduit ici — le mécanisme est la leçon, et il a exactement la forme d’un CSRF web classique, appliqué à la couche d’outils d’un agent.

Ce n’est pas un bug isolé. Le même schéma de validation d’origine manquante a produit CVE-2026-34742 (DNS rebinding dans le même SDK Go), CVE-2026-35568 (SDK Java MCP) et, plus tôt, CVE-2025-9611 dans le serveur Playwright MCP de Microsoft. Transports différents, même cause racine — voir notre note sur le DNS rebinding contre les serveurs MCP en localhost.

Pourquoi c’est important

Un serveur MCP local est rarement un jouet vide. Il est relié à un système de fichiers, à un shell, à une CLI cloud, à un dépôt de code ou à une base de données — c’est précisément le but de doter un agent d’outils. Quand un site web peut atteindre ce serveur et appeler ces outils, le navigateur devient un canal d’exfiltration et d’action vers la machine. Les conditions préalables sont banales : le serveur écoute sur loopback, tourne sans authentification (courant pour les configurations « c’est seulement sur ma machine ») et le développeur navigue sur le web dans la même session. Cette combinaison décrit une large part des postes de développement d’agents en 2026.

L’enseignement plus large, pour quiconque déploie ou exploite MCP, est que loopback n’est pas une authentification. 127.0.0.1 tient à l’écart les pairs réseau distants, mais ne fait rien contre le navigateur exécuté sur la même machine, qui est un client HTTP pleinement capable pointé là où la page de l’attaquant le lui dit. Ajoutez à cela les données de terrain sur l’exposition de MCP — 40 % des serveurs MCP distants tournent sans authentification — et la validation d’origine cesse d’être un détail.

Défenses

Le correctif est nécessaire, mais c’est l’architecture qui vous protège.

1. Mettez à jour et activez la protection. Passez à go-sdk v1.4.1+ (qui exige Go 1.25+). Le correctif ajoute la validation du Content-Type pour les requêtes POST et une vérification d’origine configurable — activez-la. Exigez Content-Type: application/json et rejetez les requêtes dont l’Origin/Host ne correspond pas à une liste blanche de valeurs locales attendues.

2. Authentifiez même en localhost. N’exécutez pas de serveurs MCP sans état ni session et sans autorisation. Un jeton porteur ou un secret de session que le navigateur ne peut deviner transforme un appel d’outil par drive-by en requête échouée.

3. Validez Host autant qu’Origin. La validation de l’en-tête Host (rejet de tout Host différent de votre valeur loopback attendue) neutralise les variantes apparentées de DNS rebinding — le serveur renvoie 403 même quand le navigateur est piégé pour atteindre 127.0.0.1.

4. Traitez le navigateur comme un attaquant adjacent. Isolez réseau les serveurs MCP de développement, écoutez sur un port haut aléatoire et placez les outils à fort impact (shell, écriture fichier, déploiement, paiements) derrière une approbation humaine explicite. Un appel d’outil par « adjoint confus » doit heurter un mur avant de toucher quoi que ce soit d’irréversible.

Statut

Élément	Valeur
CVE	CVE-2026-33252 (GHSA-89xv-2j6f-qhc8)
Composant	SDK Go MCP officiel, transport Streamable HTTP
Affecté	< 1.4.1
Corrigé	1.4.1 (exige Go 1.25+) ; commit a433a83
Sévérité	7,1 élevée — CWE-352 (CSRF)
Divulgation	Avis 2026-03-19 · NVD 2026-03-24
Apparenté	CVE-2026-34742 (DNS rebinding Go), CVE-2026-35568 (SDK Java), CVE-2025-9611 (Playwright MCP)