Le bug

Le transport serveur HTTP Streamable dans rmcp < 1.4.0 n'inspectait jamais l'en-tête Host entrant. Les serveurs MCP sont généralement liés à loopback et ne sont protégés que par la politique de même origine du navigateur — ce que le rebinding DNS contourne :

1. La victime visite http://evil.example, servi avec un TTL DNS d'une seconde.
2. La page attend que l'enregistrement soit re-résolu. Le DNS de l'attaquant répond désormais evil.example → 127.0.0.1.
3. La page appelle fetch("http://evil.example:8000/mcp", …). La requête atterrit sur le serveur MCP local de la victime, mais le navigateur la traite toujours comme étant de même origine — pas de pré-vol CORS, et le JavaScript peut lire chaque réponse.

La seule chose qui sépare cette requête d'une requête légitime est l'en-tête Host : evil.example:8000 au lieu de 127.0.0.1:8000. Sans validation, la page de l'attaquant obtient une session MCP complète et peut énumérer et appeler chaque outil exposé par le serveur — lectures de fichiers, écritures, exécution de shell, tout ce que l'assistant était configuré pour faire.

1.4.0 a ajouté StreamableHttpServerConfig::allowed_hosts, par défaut ["localhost", "127.0.0.1", "::1"], et une passerelle validate_dns_rebinding_headers() en haut du gestionnaire de requêtes qui répond 403 Forbidden sinon.

Structure

Les deux conteneurs construisent le même src/main.rs avec la même configuration serveur. La seule différence est la version de crate épinglée, donc le changement de comportement provient entièrement de la bibliothèque :

Le serveur expose whoami, read_file et run_command, et l'image est pré-remplie avec de faux identifiants dans /home/dev/project/.env et /home/dev/.ssh/id_ed25519 pour que l'exploit ait quelque chose à voler.

Exécution

Exploitez la version vulnérable :

Puis la version corrigée, pour confirmer le correctif :

Le code de sortie est 1 lorsque la cible est vulnérable et 0 lorsqu'elle ne l'est pas, donc le script s'intègre directement dans la CI.

Options utiles :

Arrêt avec docker compose down.

Pourquoi la PoC falsifie l'en-tête au lieu d'exécuter un serveur DNS

L'exploit ouvre une connexion TCP vers la cible et écrit un en-tête Host contrôlé par l'attaquant (http.client.putrequest(..., skip_host=True)). C'est octet pour octet la requête qu'un navigateur rebindé émet — le rebinding DNS n'est que le mécanisme qui fait envoyer par un navigateur un Host étranger vers un socket loopback. Le reproduire ainsi maintient le laboratoire à deux conteneurs et sans infrastructure DNS, tout en testant exactement le chemin de code concerné par la CVE.

Corriger dans votre propre serveur

Si vous ne pouvez pas mettre à niveau, terminez le point de terminaison MCP derrière un proxy inverse qui rejette les valeurs Host inconnues, et ne liez pas le serveur à 0.0.0.0 sans un tel proxy. disable_allowed_hosts() existe mais réintroduit exactement ce bug.

Références

• GHSA-89vp-x53w-74fx
• NVD — CVE-2026-42559
• Red Hat — CVE-2026-42559
• Kodem Security — CVE-2026-42559
• Spécification MCP — Sécurité des transports

Avertissement

Tout ici est intentionnellement vulnérable et existe à des fins de recherche et d'éducation. Les conteneurs exposent un outil d'exécution shell par conception — exécutez le laboratoire uniquement sur une machine qui vous appartient, et ne pointez jamais l'exploit vers un hôte que vous n'êtes pas autorisé à tester.