Le DNS rebinding transforme les serveurs MCP en localhost en surface d'attaque distante
Une vague de divulgations coordonnées 2025–2026 a touché tous les grands SDK MCP pour une même cause racine : des serveurs HTTP en localhost qui ne valident pas l'en-tête Host/Origin. La plus récente, CVE-2026-11624 dans le MCP Toolbox de Google (13 juin 2026), est notée Critique 9,4.
De quoi s’agit-il ?
En sept mois environ, une même classe de vulnérabilité a été divulguée contre la quasi-totalité des SDK officiels du Model Context Protocol (MCP) et plusieurs serveurs MCP bâtis dessus. La cause racine est identique à chaque fois : un serveur MCP en HTTP, à l’écoute sur localhost, qui ne validait pas l’en-tête Host (ou Origin), restant ainsi exposé à une attaque de DNS rebinding. La spécification MCP le signalait pourtant : sa note de sécurité sur les transports indique que « les serveurs DOIVENT valider l’en-tête Origin sur toutes les connexions entrantes pour prévenir les attaques de DNS rebinding » (spécification MCP, 2025-06-18) — mais les SDK ne l’appliquaient pas par défaut.
Ces divulgations, largement créditées au chercheur Jonathan Leitschuh, couvrent le SDK TypeScript (CVE-2025-66414, 2 déc. 2025), le SDK Java (CVE-2026-35568, 7 avr. 2026), la crate Rust rmcp (CVE-2026-42559, 29 avr. 2026), ainsi que les SDK Python et Go. La plus récente — CVE-2026-11624 dans le MCP Toolbox for Databases de Google, publiée le 13 juin 2026 et notée CVSS 4.0 9,4 (Critique) — montre que le schéma resurgit encore dans l’outillage en production (CIRCL Vulnerability-Lookup).
Comment ça marche
Le DNS rebinding est une ancienne attaque réseau-navigateur, réemployée ici contre la pile agentique. Le mécanisme est bien documenté et ne nécessite aucun exploit inédit :
- Un développeur lance un serveur MCP lié à
localhosten Streamable HTTP ou SSE — courant pour l’outillage d’agent local — généralement sans authentification. - La victime visite une page web contrôlée par l’attaquant. Le domaine de l’attaquant résout d’abord vers son propre serveur, puis est rebondi vers
127.0.0.1(changement avec un TTL très court). - Le navigateur de la victime, qui considère toujours la page comme « same-origin » pour le nom d’hôte de l’attaquant, envoie désormais des requêtes au serveur MCP local. Si le serveur vérifie seulement qu’une requête est arrivée, sans contrôler quel nom d’hôte le navigateur croyait contacter, il répond.
Comme le navigateur ne peut pas falsifier le véritable en-tête Host envoyé à l’adresse rebondie, c’est la validation de cet en-tête (contre une liste d’autorisation telle que localhost, 127.0.0.1, ::1) qui bloque l’attaque. Les serveurs qui omettaient ce contrôle laissaient une page web distante énumérer et invoquer tout outil exposé. Forme conceptuelle de la requête détournée :
# Une requête que le navigateur est piégé pour envoyer en cross-origin (valeurs illustratives)
POST /mcp HTTP/1.1
Host: attacker-rebound.example # jamais vérifié par le serveur vulnérable
Content-Type: application/json
{ "method": "tools/call", "params": { "name": "[REDACTED_TOOL]", ... } }
Selon l’avis Rust, le rayon d’impact est large : un attaquant peut « énumérer et invoquer tout outil », lire ressources et prompts, et « déclencher des effets de bord (écritures de fichiers, exécution shell, appels d’API) » — donc pour les serveurs exposant des outils de système de fichiers, de shell ou de contrôle de navigateur, cela peut dégénérer en exécution de code arbitraire sur la machine du développeur.
Pourquoi c’est important
Les serveurs MCP deviennent discrètement le composant le plus privilégié d’un déploiement d’agent : ils tournent avec les droits de l’utilisateur et arbitrent l’accès à de vrais outils. Une liaison « localhost uniquement » semble sûre, et c’est précisément ce qui rend cette classe dangereuse — l’interface de loopback n’est pas une frontière de sécurité face à un navigateur que la victime exécute déjà. Tout serveur MCP HTTP non authentifié sur un poste de développeur est joignable par n’importe quel site web ouvert.
L’ampleur fait l’histoire. Il ne s’agit pas de l’erreur d’un seul éditeur mais d’un écart spécification/implémentation répliqué dans tout un écosystème : la spec disait MUST, les SDK ont livré des valeurs par défaut non sûres (la faille TypeScript est classée CWE-1188, initialisation par défaut non sécurisée), et les serveurs aval ont hérité du défaut. Le rythme régulier, de décembre 2025 jusqu’à la CVE Critique du Toolbox de Google le 13 juin 2026, suggère que d’autres serveurs MCP portant ce schéma restent non corrigés dans la nature. À noter : les transports stdio ne sont pas concernés — seuls les serveurs HTTP/SSE le sont.
Défenses
Mettez à jour vers les versions corrigées des SDK. TypeScript @modelcontextprotocol/sdk ≥ 1.24.0, Java mcp-core ≥ 1.0.0, Rust rmcp ≥ 1.4.0 (actuel 1.5.1), et les versions Python/Go corrigées. Pour le MCP Toolbox de Google, passez à ≥ 0.25.0, qui ajoute les options --allowed-hosts/--allowed-origins (attention : les deux valent encore * par défaut et n’émettent qu’un avertissement au démarrage ; définissez-les explicitement).
Imposez des listes d’autorisation Host/Origin. Les correctifs valident l’en-tête Host contre une liste loopback (localhost, 127.0.0.1, ::1) et renvoient un HTTP 403 sinon ; le SDK TypeScript expose un middleware hostHeaderValidation(). Activez-le ; ne comptez pas sur la valeur par défaut des anciennes versions.
Placez un reverse proxy en frontal. Si vous ne pouvez pas mettre à jour, exécutez le serveur derrière nginx, Caddy ou HAProxy configuré pour rejeter toute requête dont le Host/Origin n’est pas une valeur attendue. Les frameworks imposant déjà une validation stricte CORS/Origin (p. ex. Spring AI) n’étaient pas vulnérables.
Ajoutez de l’authentification et évitez 0.0.0.0. N’exécutez pas de serveur MCP HTTP non authentifié sur des interfaces partagées. Liez-vous au loopback uniquement, exigez un jeton, et préférez stdio pour l’outillage purement local.
Auditez ce que vos outils peuvent faire. Traitez chaque outil MCP exposé localement comme joignable depuis un navigateur jusqu’à preuve du contraire, et minimisez les outils à fort impact (shell, système de fichiers sans restriction) sur tout serveur exposé en HTTP.
Statut
| Composant | Identifiant | Divulgation | Corrigé dans | Sévérité |
|---|---|---|---|---|
| Google MCP Toolbox for Databases | CVE-2026-11624 | 2026-06-13 | 0.25.0 | CVSS 4.0 9,4 (Critique) |
SDK Rust (rmcp) | CVE-2026-42559 | 2026-04-29 | 1.4.0 | CVSS 3.1 8,8 (Élevée) |
SDK Java (mcp-core) | CVE-2026-35568 | 2026-04-07 | 1.0.0 | CVSS 4.0 7,6 (Élevée) |
| SDK TypeScript | CVE-2025-66414 | 2025-12-02 | 1.24.0 | CVSS 4.0 7,6 (Élevée) |
| SDK Python / Go | GHSA-9h52-p55h-vw2f / GHSA-xw59-hvm2-8pj6 | 2025–2026 | corrigé | Élevée |
| Faiblesse commune | CWE-346 (Origin Validation Error) / CWE-1188 | — | — | — |
| Non concernés | transports stdio ; frameworks à CORS strict (p. ex. Spring AI) | — | — | — |
Sources
- → https://vulnerability.circl.lu/vuln/cve-2026-11624
- → https://github.com/modelcontextprotocol/rust-sdk/security/advisories/GHSA-89vp-x53w-74fx
- → https://github.com/modelcontextprotocol/java-sdk/security/advisories/GHSA-8jxr-pr72-r468
- → https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-w48q-cv73-mx4w
- → https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning