Le serveur verify-mcp de Kluster AI fait confiance à toute session de navigateur capable d’atteindre son point de terminaison /stream.

Lorsque le service est exposé en HTTP et lié à 0.0.0.0, une attaque par DNS rebinding peut transformer le navigateur d’une victime en un proxy qui pilote l’API depuis l’Internet ouvert.

Lors de nos tests, cette technique nous a permis d’invoquer l’outil verify à distance et de consommer des crédits Kluster sans le consentement de l’utilisateur.

Résumé

  • Vecteur d’attaque : le DNS rebinding abuse du modèle de confiance du navigateur pour rediriger un nom de domaine d’un hôte de l’attaquant vers 127.0.0.1, contournant ainsi les protections de la politique de même origine (Same-Origin Policy).
  • Composant exposé : le serveur verify-mcp de Kluster expose /stream en HTTP simple et accepte les requêtes en se fondant uniquement sur les en-têtes Host fournis par le client.
  • Résultat observé : après le rebinding, du JavaScript contrôlé par l’attaquant a pu piloter l’outil verify comme s’il s’agissait de l’utilisateur local, consommant des crédits payants.

D’autres outils traités sur ce site présentent la même faille : Vulnérabilité de DNS rebinding dans le transport SSE du Vet MCP Server et Le Neo4j MCP Cypher Server est vulnérable à une prise de contrôle de la base de données via DNS rebinding.

Analyse technique

L’attaque se déroule en deux phases DNS, couplées à une charge utile HTML/JavaScript légère :

  1. Liaison initiale à l’infrastructure de l’attaquant. La victime visite un site contrôlé par l’attaquant. La première résolution DNS pointe vers l’adresse IP publique de l’attaquant, ce qui nous permet de servir un script qui interroge le point de terminaison de Kluster.
  2. Rebinding vers localhost. Une fois la page chargée, le serveur DNS de l’attaquant répond aux requêtes suivantes pour le même hôte avec 127.0.0.1. Les navigateurs réutilisent le nom mis en cache, de sorte que les appels fetch ultérieurs basculent silencieusement vers l’interface de bouclage (loopback) de la victime tout en conservant la chaîne d’origine initiale.
  3. Piloter l’API verify. Comme verify-mcp autorise les requêtes HTTP de n’importe quelle origine et ne valide pas les en-têtes Host ou Origin, notre script a réussi à envoyer (POST) des tâches à /stream, déclenchant des exécutions de vérification consommant des crédits.

Ce schéma n’est pas propre à Kluster, mais la combinaison du transport HTTP et de l’absence de validation des en-têtes a rendu l’exploitation triviale.

Impact

  • Abus du service : des acteurs distants peuvent consommer les crédits de vérification de Kluster ou inonder l’API de requêtes, entraînant des pertes financières ou une limitation de débit (rate limiting) pour les utilisateurs légitimes.

Recommandations

Pour Kluster AI

  • Validez strictement les en-têtes Host et Origin, en rejetant les requêtes qui ne correspondent pas à une liste d’autorisation explicite (localhost, 127.0.0.1).
  • Introduisez une authentification ou des jetons d’API, même pour les sessions locales, afin de garantir que seuls les appelants de confiance peuvent invoquer des actions consommant des crédits.

Pour les opérateurs et utilisateurs MCP

  • Partez du principe que les services localhost sont accessibles via le navigateur en présence de DNS rebinding ; surveillez les journaux à la recherche de noms d’origine inattendus.
  • Privilégiez HTTPS (avec des certificats appropriés) et une validation explicite des en-têtes pour tout outil exposé au-delà de l’interface de bouclage.
  • Sensibilisez les développeurs à fermer les agents locaux lorsqu’ils naviguent sur des sites non fiables, ou utilisez la segmentation réseau pour isoler les services d’agents du profil de navigateur par défaut.

Réflexions finales

Le DNS rebinding continue de brouiller la frontière entre « local » et « distant » pour les outils MCP.

En renforçant les transports, en validant les métadonnées des requêtes et en exigeant une authentification, les fournisseurs de plateformes peuvent aider les développeurs à être plus sûrs.

Chronologie

  • 2025-07-17 : rapport initial soumis à la sécurité de Kluster AI.
  • 2025-07-17 : Kluster a accusé réception le jour même.
  • 2025-08-29 : relance envoyée à Kluster AI pour connaître l’état de la correction.
  • 2025-10-16 : avis de sécurité technique publié sur mcpsec.dev.