Tu localhost no es privado: Protegiendo entornos de desarrollo contra SSRF y rebinding DNS en localhost

La mayoría de los desarrolladores consideran localhost como un límite de confianza. Todo lo bound a 127.0.0.1 se asume accesible solo por ti. Esa suposición ha fallado repetidamente, en navegadores, herramientas de IA, servidores de desarrollo y entornos de contenedores.

Este artículo cubre dos clases de ataques relacionados, cómo afectan a las máquinas de desarrollo, los cambios en los navegadores en los últimos dos años y qué hacer al respecto. También explica dónde ayuda una herramienta de túnel como InstaTunnel y dónde no.

Dos clases de ataque, una falsa suposición

Localhost SSRF es una falsificación de solicitudes del lado del servidor dirigida a la loopback. Una aplicación obtiene una URL que controla el atacante (un webhook, una imagen, una vista previa de enlace) y la apunta a 127.0.0.1, 0.0.0.0 o una dirección interna. El servidor realiza la solicitud desde dentro del límite de confianza, a servicios que nunca esperaron llamadas externas.

Rebinding DNS funciona desde el navegador. Una víctima visita la página del atacante. El dominio del atacante primero resuelve a su servidor, luego a 127.0.0.1, por lo que el navegador sigue tratando las solicitudes como de misma origen, aunque lleguen al servicio local de la víctima. El aviso de Vite describe esta cadena: el atacante cambia la respuesta DNS para que apunte a 127.0.0.1 u otra dirección privada, y un servidor HTTP que no valida la cabecera Host no puede distinguir la diferencia.

Ambos dependen de la misma mala suposición: acceder a un puerto local significa que el llamador es confiable.

La vulnerabilidad del día 0.0.0.0

En agosto de 2024, Oligo Security descubrió el “Día 0.0.0.0”, un fallo lógico en cómo los principales navegadores (Chromium, Firefox, Safari) manejaban solicitudes a 0.0.0.0. Oligo lo reportó a los fabricantes en abril de 2024.

• El mecanismo. Private Network Access (PNA) pretendía evitar que sitios públicos alcanzaran direcciones privadas. Pero 0.0.0.0 no estaba en la lista de rangos privados o locales, por lo que las solicitudes a esa dirección pasaron sin ser bloqueadas.
• Afectados. El problema afectó macOS y Linux, pero no Windows. El investigador de Oligo dijo que sitios públicos podían acceder a cualquier puerto abierto en el host, pero sin poder leer la respuesta, por lo que la exposición es mayormente a solicitudes ciegas que cambian estado.
• Antigüedad. No es nuevo en el sentido de “reciente”. La divulgación de Oligo resonó con un fallo reportado a Mozilla en 2006.
• Las soluciones. Chrome empezó a bloquear 0.0.0.0 en Chromium 128, con un despliegue gradual que terminará en Chrome 133. Apple modificó WebKit para bloquearlo. Mozilla cambió el estándar Fetch para bloquearlo, pero, en ese momento, no tenía una solución en Firefox.

El despliegue fue desigual. Cuando Oligo publicó su análisis en 2025 sobre la vulnerabilidad MCP Inspector (más abajo), todavía listaba el comportamiento de 0.0.0.0 como no resuelto en Chromium y Firefox. No asumas que todos los navegadores de tu equipo están protegidos.

Explotación real: MCP Inspector

CVE-2025-49596 afectó al MCP Inspector, una herramienta de desarrollo para probar servidores MCP. Se calificó como Crítica (CVSS 9.4). Versiones anteriores a 0.14.1 no tenían autenticación entre el cliente del Inspector y su proxy local. Al encadenar una solicitud tipo CSRF con el Día 0.0.0.0, un sitio malicioso podía enviar comandos a ese proxy y ejecutar código en la máquina del desarrollador. La versión 0.14.1, lanzada el 13 de junio de 2025, añadió un token de sesión por defecto y comprobación del host.

Por qué las herramientas de IA empeoraron esto

Las herramientas de IA locales suelen correr servidores HTTP o WebSocket sin autenticación en loopback, porque “solo es local”. Tres casos recientes muestran ese patrón.

SDKs de MCP (diciembre 2025). CVE-2025-66416 (SDK en Python, arreglado en 1.23.0) y CVE-2025-66414 (SDK en TypeScript, arreglado en 1.24.0) se divulgaron porque no habilitaban protección contra rebinding DNS por defecto en servidores HTTP. Un servidor MCP sin autenticar en localhost podía ser alcanzado desde un sitio malicioso, que podía invocar sus herramientas. Los servidores usando transporte stdio no se ven afectados.

ClawJacked (febrero 2026). Oasis Security mostró que cualquier sitio podía secuestrar un agente OpenClaw local. Los navegadores no bloquean conexiones WebSocket a localhost por motivos de origen cruzado, por lo que JavaScript en la página podía abrir un socket con la puerta de enlace y adivinar su contraseña. La puerta de enlace eximía localhost de límites de tasa y aprobaba automáticamente el emparejamiento de dispositivos desde localhost, así que una suposición exitosa daba acceso persistente. La solución se implementó en aproximadamente un día.

NVIDIA NemoClaw y Ollama (agosto 2026). Oasis Security informó que una página web maliciosa podía tomar control de la instancia Ollama detrás de NemoClaw en una configuración. Ollama arregló su fallo de rebinding DNS (CVE-2024-28224) en v0.1.29 validando la cabecera Host. El informe indica que esa validación se omite cuando Ollama está en una dirección no loopback, y que la ruta en Windows establece OLLAMA_HOST=0.0.0.0:11434. El atacante podría reescribir la plantilla de chat del modelo para insertar instrucciones persistentes. La investigación no tiene CVE, y no se reportaron explotaciones hasta el 25 de agosto de 2026. Según el investigador, una solución cubrió macOS y Linux en NemoClaw v0.0.35, pero no Windows ni WSL. Verifica el estado actual antes de confiar en esto.

La lección es que enlazar a 0.0.0.0 puede desactivar silenciosamente protecciones que solo aplican a loopback.

Servidores de desarrollo y entornos de contenedores

Vite (CVE-2025-24010). Antes de la solución, cualquier sitio podía enviar solicitudes al servidor de desarrollo y leer las respuestas, por configuraciones CORS permisivas y falta de validación Origin en conexiones WebSocket. Esto incluso afectaba a servidores solo en la máquina local. Está arreglado en Vite 6.0.9, 5.4.12 y 4.5.6. La opción server.allowedHosts permite localhost, *.localhost y direcciones IP por defecto. La documentación de Vite advierte que configurarlo en true permite que cualquier sitio alcance tu servidor de desarrollo mediante rebinding DNS, y recomienda una lista explícita.

Docker Desktop (CVE-2025-9074). La API de Engine de Docker era alcanzable en 192.168.65.7:2375 desde cualquier contenedor, sin autenticación. La vulnerabilidad fue calificada con 9.3 (CVSS) y arreglada en Docker Desktop 4.44.3. Afectó Windows y macOS, pero no Linux, porque en Linux se usa un socket local en lugar de un puerto TCP. SOCRadar la clasifica como SSRF: una solicitud forjada desde dentro de un contenedor alcanzaba un plano de control que asumía que todos los llamadores eran confiables.

Lo que hacen ahora los navegadores

El plan anterior de Chrome, Private Network Access con preflight CORS, se suspendió por problemas de compatibilidad. Antes de pausar, Chrome añadió 0.0.0.0/8 a los rangos locales de PNA.

La alternativa es Local Network Access (LNA):

• Chrome 142 (28 de octubre de 2025) limita solicitudes de sitios públicos a direcciones locales o loopback tras una solicitud de permiso. Otros navegadores Chromium siguieron.
• Chrome 145 dividió el permiso en local-network y loopback-network, según un problema de seguimiento del equipo de Chrome. El mismo problema indica que Chrome 147 extiende las restricciones a WebSocket y WebTransport, y que la política temporal de exclusión empresarial se eliminará en Chrome 156.
• Firefox tiene un aviso similar. La página de soporte de Mozilla indica que se aplica desde la versión 149 para usuarios con Protección Mejorada contra Rastreo Estricta, con despliegue gradual a todos los usuarios desde la versión 151.

Son mejoras reales, pero son una defensa en profundidad. Solicitan permisos a los usuarios y limitan solicitudes entre sitios; no hacen seguro un servicio local sin autenticación. Rebinding DNS y software malicioso en la máquina son problemas separados. La solución estándar para rebinding, como se indica en la cobertura de la investigación NemoClaw, es verificar cabeceras Host y Origin en el servidor. Considera los controles del navegador como una segunda capa.

Cómo reforzar la aplicación: una lista de verificación

1. Autentica todos los servicios locales, incluso en loopback. Usa un token aleatorio, no “solo localhost”. CVE-2025-49596 y ClawJacked se debieron a autenticación débil o ausente.
2. Lista blanca la cabecera Host y rechaza todo lo demás. Es la defensa principal contra rebinding DNS. Nunca uses comodín o configuración “permitir todo” (como allowedHosts: true en Vite).
3. Valida Origin en solicitudes que cambian estado y en actualizaciones WebSocket. CORS no regula las conexiones WebSocket, por lo que no puede protegerlas.
4. Aplica límites de tasa también en localhost, y no apruebes automáticamente emparejamientos o registros desde loopback.
5. Enlaza a 127.0.0.1, no a 0.0.0.0, a menos que necesites acceso LAN. Si un contenedor o WSL fuerza un enlace más amplio, verifica qué controles de host siguen activos.
6. Prefiere stdio o sockets locales en lugar de TCP para comunicación solo local. El transporte stdio de MCP no está expuesto a ataques del navegador, y la arquitectura Linux de Docker evitó CVE-2025-9074 por esa razón.
7. Actualiza. Las versiones mencionadas son el mínimo: Vite 6.0.9 / 5.4.12 / 4.5.6, MCP Inspector 0.14.1, SDK en Python 1.23.0, SDK en TypeScript 1.24.0, Ollama 0.1.29, Docker Desktop 4.44.3.

Cómo reforzar el fetch del lado del servidor (SSRF en localhost)

Si tu backend obtiene URLs proporcionadas por el usuario:

• Prefiere una lista blanca. La Guía de Prevención SSRF de OWASP indica que las listas negras son vulnerables. Donde sea posible, compara el host con destinos conocidos y construye la solicitud tú mismo.
• Bloquea todas las representaciones locales, no solo 127.0.0.1. OWASP lista 127.0.0.0/8, 0.0.0.0/8 y ::1/128 para localhost. Las listas públicas muestran muchas variantes: 127.1, 0, [::], decimal 2130706433, hexadecimal 0x7f000001, y formas IPv4-mapped IPv6.
• Resuelve, valida y fija. Busca registros A y AAAA, comprueba cada dirección contra tus rangos bloqueados, y conecta a la IP validada. De lo contrario, un hostname puede pasar validación y volver a resolverse a una dirección privada para la solicitud real.
• Revalida redirecciones. Un destino de redirección es una segunda solicitud que requiere las mismas validaciones.
• Bloquea rangos locales y privados, incluyendo la dirección de metadatos en la nube 169.254.169.254.

Dónde encaja un túnel

Un túnel invierte tu exposición: en lugar de un servicio localhost solo accesible desde tu navegador, tienes un servicio accesible para cualquiera con la URL. Es útil para webhooks, callbacks OAuth, demos y pruebas MCP, pero la lista de verificación anterior se vuelve obligatoria.

Un túnel tampoco soluciona los problemas anteriores. No puede añadir validación Host a tu servidor de desarrollo ni autenticación a tu endpoint MCP. Lo que sí puede hacer es poner control de acceso delante del servicio local, para no depender de los valores predeterminados del servicio. Según la documentación de InstaTunnel:

• Autenticación en el borde. --password y --auth user:pass protegen un túnel. Requieren plan Pro o Business. Desde CLI 1.1.24, la configuración de contraseña y autenticación básica se aplica antes de reenviar las solicitudes a tu máquina.

instatunnel 3000 --subdomain acme-qa --auth qa:review-secret

• Túneles MCP con token bearer. --mcp requiere plan Pro o Business. La documentación muestra generar un token con node -e "console.log(require('crypto').randomBytes(32).toString('hex'))" y usarlo en la cabecera Authorization: Bearer. Tu servidor MCP debe validar el token; el cliente no requiere autenticación por defecto.

instatunnel 8787 --mcp --transport v2 --subdomain mymcp

• Políticas de tráfico. La documentación de políticas de tráfico de InstaTunnel describe reglas de permitir y bloquear IP por CIDR, cabeceras, límites por IP/clave API/usuario (que devuelven 403 o 429 cuando se bloquea), y registros de auditoría. Gestionadas por administradores en /admin/policies.
• Visibilidad y limpieza. --logs (Pro/Business) obtiene registros de solicitudes, y --kill <subdomain> detiene un túnel. Para enlaces QA, se recomienda rotar credenciales y detener el túnel tras revisión.

Un detalle práctico: si tu túnel envía su hostname público en la cabecera Host, una lista blanca como allowedHosts en Vite rechazará esa cabecera hasta que añadas ese hostname exacto. Añade el hostname específico que controlas, no un comodín ni true. Verifica qué envía tu túnel antes de confiar en esto.

Resumen

• Día 0.0.0.0 es un fallo de navegador de 2024, mitigado de forma desigual. Se explotó en herramientas de desarrollo como MCP Inspector.
• Rebinding DNS sigue reapareciendo en herramientas de desarrollo, desde Ollama en 2024, SDKs MCP en 2025, hasta NemoClaw en 2026. La solución siempre está en el servidor: autenticar y validar Host y Origin.
• Solicitudes con permisos en navegador (Chrome 142+, Firefox 149+) reducen la exposición, pero no reemplazan esas verificaciones.
• Los fetch del servidor necesitan listas blancas, resolución completa de direcciones y conexiones fijadas.
• Los túneles deben añadir autenticación y control de acceso delante de tu servicio, nunca ser la única barrera.