El servidor verify-mcp de Kluster AI confía en cualquier sesión de navegador que pueda alcanzar su endpoint /stream.

Cuando el servicio se expone por HTTP y se enlaza a 0.0.0.0, un ataque de DNS rebinding puede convertir el navegador de una víctima en un proxy que controla la API desde la Internet abierta.

Durante nuestras pruebas, esta técnica nos permitió invocar la herramienta de verificación de forma remota y consumir créditos de Kluster sin el consentimiento del usuario.

Resumen

  • Vector de ataque: el DNS rebinding abusa del modelo de confianza del navegador para reapuntar un nombre de dominio desde un host del atacante a 127.0.0.1, eludiendo las protecciones de la política del mismo origen (Same-Origin Policy).
  • Componente expuesto: el servidor verify-mcp de Kluster expone /stream a través de HTTP plano y acepta solicitudes basándose únicamente en las cabeceras Host suministradas por el cliente.
  • Resultado observado: tras el rebinding, JavaScript controlado por el atacante pudo controlar la herramienta de verificación como si fuera el usuario local, consumiendo créditos de pago.

Otras herramientas tratadas en este sitio fallan de la misma manera: Vulnerabilidad de DNS rebinding en el transporte SSE del Vet MCP Server y El Neo4j MCP Cypher Server es vulnerable a la toma de control de la base de datos mediante DNS rebinding.

Análisis técnico

El ataque se desarrolla en dos fases de DNS, junto con una carga útil ligera de HTML/JavaScript:

  1. Enlace inicial a la infraestructura del atacante. La víctima visita un sitio controlado por el atacante. La primera resolución DNS apunta a la IP pública del atacante, lo que nos permite servir un script que sondea el endpoint de Kluster.
  2. Rebinding a localhost. Después de que la página se carga, el servidor DNS del atacante responde a las consultas siguientes para el mismo host con 127.0.0.1. Los navegadores reutilizan el nombre almacenado en caché, de modo que las llamadas fetch posteriores se redirigen silenciosamente a la interfaz de loopback de la víctima, conservando la cadena de origen original.
  3. Controlar la API de verificación. Dado que verify-mcp permite solicitudes HTTP desde cualquier origen y no valida las cabeceras Host ni Origin, nuestro script logró enviar (POST) trabajos a /stream, desencadenando ejecuciones de verificación que consumen créditos.

Este patrón no es exclusivo de Kluster, pero la combinación de transporte HTTP y la falta de validación de cabeceras hizo que la explotación fuera trivial.

Impacto

  • Abuso del servicio: actores remotos pueden consumir créditos de verificación de Kluster o saturar la API, causando pérdidas económicas o limitación de tasa (rate limiting) para los usuarios legítimos.

Recomendaciones

Para Kluster AI

  • Validar de forma estricta las cabeceras Host y Origin, rechazando las solicitudes que no coincidan con una lista de permitidos explícita (localhost, 127.0.0.1).
  • Introducir autenticación o tokens de API incluso para las sesiones locales, a fin de garantizar que solo los llamantes de confianza puedan invocar acciones que consumen créditos.

Para operadores y usuarios de MCP

  • Asuma que los servicios de localhost son accesibles a través del navegador en presencia de DNS rebinding; vigile en los registros los nombres de origen inesperados.
  • Prefiera HTTPS (con certificados adecuados) y una validación explícita de cabeceras para cualquier herramienta expuesta más allá de la interfaz de loopback.
  • Enseñe a los desarrolladores a cerrar los agentes locales al navegar por sitios no confiables, o utilice la segmentación de red para aislar los servicios de agentes del perfil de navegador predeterminado.

Reflexiones finales

El DNS rebinding sigue difuminando la frontera entre “local” y “remoto” para las herramientas MCP.

Al reforzar los transportes, validar los metadatos de las solicitudes y exigir autenticación, los proveedores de plataformas pueden ayudar a los desarrolladores a ser más seguros.

Cronología

  • 2025-07-17: informe inicial enviado a seguridad de Kluster AI.
  • 2025-07-17: Kluster acusó recibo el mismo día.
  • 2025-08-29: consulta de seguimiento enviada a Kluster AI solicitando el estado de la remediación.
  • 2025-10-16: aviso de seguridad técnico publicado en mcpsec.dev.