Cadena de explotación NemoClaw expone Ollama a acceso no autenticado y altera plantillas del chat

Qué ha ocurrido (hechos confirmados): Investigadores de Oasis Security han publicado un informe que describe una cadena de explotación contra la configuración de NemoClaw que puede permitir a una página web controlada por un atacante acceder sin autenticación a una instancia local de Ollama y modificar el “chat template” del modelo para insertar instrucciones ocultas que persistan en conversaciones posteriores. Oasis Security afirma que notificó el problema al equipo PSIRT de NVIDIA antes de la publicación; no hay, según el informe, un identificador CVE, ni un rango de versiones afectadas ni una versión parcheada señaladas por Oasis. Hasta el 25 de agosto de 2026 no se ha reportado explotación en campo.

Cómo funciona técnicamente la cadena de ataque (explicación técnica): El vector aprovecha dos hechos concretos: primero, que NemoClaw puede iniciar Ollama con OLLAMA_HOST=0.0.0.0:11434, lo que hace que el servicio de inferencia escuche en todas las interfaces en lugar de solo en loopback; segundo, que la API en el puerto 11434 no exige autenticación y su protección frente a orígenes web depende de comprobaciones de Host/Origin y de un proxy tokenizado que, en algunas configuraciones (especialmente rutas que usan WSL/Docker Desktop en Windows), no está presente o no aplica.

Con la API expuesta de ese modo, un atacante puede servir una página web que primero responde desde su dominio legítimo y luego, mediante una técnica de DNS rebinding, hace que ese dominio resuelva a 127.0.0.1. El navegador mantiene la política de mismo origen (same-origin) y, si el servidor no valida correctamente el Host u Origin, el navegador enviará peticiones que la API de Ollama aceptará como si fueran de la misma procedencia. Desde allí la petición a /api/create puede escribir un template Go que modifica cómo se renderizan los mensajes estructurados; la plantilla maliciosa puede añadir texto a cada system message en tiempo de inferencia, y este cambio queda almacenado a nivel de modelo, invisible para clientes posteriores que usan la API.

Qué se ha confirmado en el software: Revisiones públicas del repositorio de NemoClaw muestran que en la versión de agosto se añadió una comprobación (v0.0.106) que impide iniciar el proxy local si detecta que el backend Ollama está enlazado a una interfaz no loopback —pero esa prevención no cubre todas las rutas de ejecución. En particular, la ruta Windows-host/Wsl/Docker Desktop usada para acceder al daemon desde contenedores suele configurar OLLAMA_HOST=0.0.0.0 para permitir esa accesibilidad, y NemoClaw no arranca el proxy en esos caminos. Además, no se ha encontrado en el repositorio ninguna validación de integridad de la plantilla de chat que impida modificaciones remotas del template.

Consecuencias prácticas: Si se reproduce la cadena en una máquina objetivo, un simple sitio web malicioso abierto en el navegador del usuario local podría tomar control del agente Ollama que sirve a OpenClaw/OpenShell/NemoClaw. Las consecuencias incluyen: persistencia de instrucciones maliciosas en el comportamiento del modelo (manipulación de respuestas futuras), ejecución indirecta de herramientas que el agente tenga conectadas (p. ej. llamadas a ejecutables locales o APIs de terceros), exfiltración de datos locales y la creación de agentes “secuestrados” que actúen como pivote dentro del entorno del operador. La explotación no requiere que la API sea accesible desde la red externa: basta con que el navegador del usuario local alcance el puerto 11434 en localhost.

Qué está confirmado y qué es incierto: Confirmado: la existencia del método (binding a 0.0.0.0 + falta de autenticación + DNS rebinding) y que NemoClaw presenta caminos de arranque que dejan al daemon accesible en 0.0.0.0 en ciertas plataformas; confirmado también que una modificación de plantilla puede persistir a nivel de modelo. Incierto/estimado: qué navegadores y versiones concretas son susceptibles en la práctica (el informe no especifica contra cuáles navegadores/OS se verificó la cadena), y si existe explotación activa en entornos reales más allá de pruebas de laboratorio. Tampoco hay una lista pública de versiones afectadas ni un parche oficial señalado por Oasis en su aviso inicial.

Medidas concretas y verificables que deben aplicar los operadores (ordenadas por facilidad e impacto):

1) Verificar si su instancia local de Ollama está escuchando en 0.0.0.0 y, si es así, cambiarla a loopback. En sistemas Linux use, por ejemplo: ss -ltnp | grep 11434 o netstat -plnt y compruebe la columna “Local Address”. Si aparece 0.0.0.0:11434, reconfigure la unidad de servicio para exportar OLLAMA_HOST=127.0.0.1:11434 y reinicie el servicio.

2) Bloquear el acceso a 11434 desde interfaces de red no loopback con reglas de firewall (ej.: iptables/nftables o reglas de Windows Firewall) para impedir conexiones desde la LAN o internet. Esto mitiga exposiciones accidentales incluso si la variable de entorno no se corrige inmediatamente.

3) Revisar la configuración de Docker Desktop / WSL2 en Windows: no permita que contenedores o WSL accedan al daemon en el host a través de host.docker.internal o mediante binding público si no es estrictamente necesario. En entornos donde esa conectividad sea imprescindible, aplique controles adicionales (firewall local, revocar acceso a herramientas críticas, ejecutar el agente en VM aisladas).

4) Limitar las capacidades del agente: reduzca o desactive las herramientas y capacidades de llamada a APIs/ejecutables que el agente pueda invocar. Trate los modelos y sus entornos como componentes que pueden ser comprometidos; no confíe en el aislamiento del sandbox para proteger secretos o acceso a infraestructuras críticas.

5) Comprobar plantillas y modelos tras sospecha: consulte la API administrativa (/api/show u otras rutas administrativas documentadas) para detectar cambios en plantillas y contexto del modelo. Si detecta plantillas inesperadas, restaure desde copia segura o reentrene/reimplante el modelo y rote credenciales/keys que el agente pudiera usar.

6) Actualizar y seguir publicaciones del proveedor: aunque Oasis Security notificó a NVIDIA, la ausencia de un CVE o un parche claro obliga a operadores a seguir tanto al repositorio de NemoClaw como a las notas de Ollama y a aplicar parches o cambios de configuración recomendados por los equipos responsables. Consulte la documentación oficial de Ollama sobre configuración segura y protecciones contra DNS rebinding: https://ollama.com/docs. Para entender la amenaza técnica del DNS rebinding y cómo mitigarlo en aplicaciones web, véase la documentación de OWASP: https://owasp.org/www-community/attacks/DNS_Rebinding.

Recomendaciones para usuarios finales y desarrolladores: Usuarios: no abrir páginas desconocidas o no confiables en máquinas donde se desarrollen o ejecuten agentes locales; cierre pestañas innecesarias y evite ejecutar navegadores con privilegios elevados. Desarrolladores/operadores: exigir autenticación en la API de inferencia, validar el header Host en el servidor (permitir solo valores autorizados) y añadir controles de integridad sobre plantillas de chat y metadatos del modelo para que modificaciones administrativas queden registradas y revisables. Las validaciones del Host/Origin y la implementación de tokenización/proxy deben funcionar en todas las rutas de despliegue, incluidas WSL y entornos con Docker Desktop.

Contexto adicional y lecturas: La técnica de “plantar” instrucciones manipulando plantillas del renderizado del prompt se ha documentado antes en otros proyectos de agentes. Además, la mitigación clásica para ataques por DNS rebinding es comprobar el Host en el servidor y restringir bindings a loopback, medidas que ya han sido recomendadas en avisos previos relacionados con Ollama.

En resumen: existe una cadena plausible y documentada para que un navegador local, mediante DNS rebinding y una API de Ollama enlazada a 0.0.0.0 sin autenticación, modifique plantillas de chat y altere el comportamiento persistente de un agente. Actuar sobre la configuración de binding, aplicar reglas de firewall y limitar capacidades del agente reduce el riesgo de explotación hasta que haya un parche y indicaciones oficiales que cubran todas las rutas de despliegue.