Una investigación de Oasis Security pone el foco en un escenario inquietante para quienes ejecutan agentes de forma local con NVIDIA NemoClaw. Según el informe, una página web maliciosa podría ser capaz de envenenar el modelo local alterando su plantilla de chat, logrando que instrucciones ocultas se apliquen en conversaciones posteriores.
El punto clave es que el acceso descrito se daría a través del backend local de inferencia Ollama y, en el flujo descrito, no sería necesaria autenticación para alcanzar la API. Aunque el reporte no incluye un identificador CVE ni un rango de versiones afectadas, la amenaza destaca por su forma de explotación: manipular cómo el modelo transforma mensajes estructurados en texto antes de procesarlos.
Qué problema se describe en NemoClaw
El informe explica que NemoClaw inicia Ollama de distintas maneras según el entorno. En ciertos casos, la instancia del servidor del modelo queda expuesta de manera que un atacante podría modificar la chat template a través de la API de Ollama.
Al alterar esa plantilla, el atacante podría inyectar texto controlado por él que se añada a cada system message durante el tiempo de inferencia. Este detalle importa: el cambio no se limitaría a una sola conversación, sino que podría persistir para usos futuros, incluso si el agente proporciona su propio prompt del sistema.
Oasis Security resume la idea con una advertencia práctica: “el sandbox protege el endpoint”, pero si el atacante logra tomar el control del agente, también consigue acceso a sus capacidades y herramientas. En ese contexto, una manipulación a nivel de plantilla puede convertirse en una puerta para ejecutar instrucciones inesperadas.
Por qué la API local de Ollama es crítica
De acuerdo con el reporte, la API de Ollama que escucha en el puerto 11434 no exige autenticación. En su lugar, el control se apoya en capas de mediación para bloquear solicitudes originadas desde navegadores.
El problema se agrava cuando la instancia no está limitada únicamente a loopback (direcciones locales como 127.0.0.1). En esas configuraciones, el reporte indica que el chequeo relacionado con la cabecera Host puede omitirse. Luego, la capa de CORS podría interpretar la solicitud como si fuera del mismo origen, y permitir el acceso.
¿Cómo encaja esto con una página maliciosa? La cadena descrita se apoya en que el navegador del usuario realiza las peticiones hacia la API local mientras el encabezado Origin y el Host pueden reflejar el dominio que el atacante controla.
El papel del DNS rebinding
El reporte no solo describe un fallo conceptual en cabeceras, sino también un mecanismo para cerrar la distancia entre “internet” y “localhost”: DNS rebinding.
La lógica es la siguiente: el dominio del atacante primero resuelve hacia el servidor del atacante y, en un segundo momento, vuelve a resolver hacia 127.0.0.1. Con esto, el navegador mantiene la expectativa de mismo origen, mientras que el tráfico termina llegando a la API local.
Como el flujo depende de validaciones de cabeceras (por ejemplo, verificar Host y Origin), el informe señala que esa clase de ataque suele mitigarse con comprobaciones del lado del servidor contra valores autorizados.
Relación con parches previos en Ollama
La investigación conecta el riesgo con un historial ya conocido. Para ataques similares contra la API de Ollama, se documentó un enfoque y se publicó una corrección previa.
En concreto, se menciona que Ollama envió un arreglo en la versión v0.1.29 con fecha de 14 de marzo de 2024. Además, se refiere una asesoría posterior, asociada a CVE-2024-28224, donde se recomendaba validar el Host en el servidor para permitir únicamente valores autorizados.
Este contexto sugiere que el problema no es “nuevo” en el sentido de técnicas de ataque, pero en NemoClaw el reporte afirma que ciertos detalles de configuración y de implementación pueden reabrir el vector si se cumplen condiciones específicas.
Diferencias de configuración según el entorno
Un punto especialmente relevante del informe es que NemoClaw no se comporta igual en todos los sistemas. El modo de exposición de Ollama depende de rutas y del sistema operativo/entorno donde se ejecute.
En términos generales, el reporte describe que:
- En hosts no WSL, Ollama se mantiene en 127.0.0.1:11434 mediante un proxy reverso con token, y se usa otra interfaz para el acceso (en el reporte se cita 0.0.0.0:11435 para ese esquema).
- En Docker Desktop sobre WSL, el proxy puede omitirse porque el contenedor alcanza el loopback del host a través de host.docker.internal.
- En un camino para Windows host, se ajusta OLLAMA_HOST=0.0.0.0:11434 para que los contenedores de Docker Desktop puedan llegar al daemon. En esa ruta, se indica que no se requiere autenticación en el puerto 11434.
Además, el informe remite a una recomendación del propio ecosistema de integración, donde se aconseja usar OLLAMA_HOST=0.0.0.0 en WSL2 o dentro de contenedores, y señala que se identificó previamente que esa vinculación podría hacer que la instancia sea accesible fuera de la máquina local.
Persistencia del envenenamiento y límites de detección
Una de las afirmaciones más preocupantes del reporte es que el cliente no puede “detectar o prevenir” la alteración una vez que se aplica. La razón es que la template a nivel de modelo sería una propiedad que no resulta visible para consumidores de la API.
Desde el punto de vista del atacante, el flujo descrito usa la ruta /api/create para escribir una plantilla modificada. Esa plantilla se encarga de cómo se renderiza el arreglo de mensajes estructurados hacia texto sin procesar antes de que el modelo lo lea.
Según el reporte, el resultado es que el modelo “hereda” instrucciones en cada inferencia futura, incluso cuando el agente incluye su propio system prompt. Eso convierte el problema en algo más que un ataque temporal de sesión.
¿Hay alguna comprobación defensiva en el propio NemoClaw?
El texto incluye un hallazgo de verificación del repositorio por parte de The Hacker News en una fecha específica. Se revisó el repositorio en un commit concreto y se encontró un control relacionado con el proxy.
El reporte señala que el proxy local rehúsa iniciarse si el backend de Ollama no está configurado para enlazar a una interfaz de loopback. Cuando la condición no se cumple, el proxy se cierra con un código de estado específico e imprime una instrucción. También se indica que existe una variable de entorno que permite saltar ese chequeo, aunque no se recomienda.
Al mismo tiempo, el informe explica que ese chequeo puede no aplicarse en ciertas rutas de plataforma. Por ejemplo, se menciona que NemoClaw no inicia el proxy en caminos WSL y que una configuración de Windows host sería una de las situaciones donde el chequeo por defecto no llega a la ruta donde se define el bind en 0.0.0.0.
Qué se sabe y qué no (por ahora)
Hasta el momento de la publicación descrita en el artículo base, el reporte no presenta un identificador CVE ni un rango de versiones afectadas, ni una versión corregida. Eso significa que, para operadores, el control práctico se traduce en revisar configuración, exposición de red y cómo se publica el puerto 11434 en su entorno.
El informe también indica que no se reportaron casos de explotación conocidos a la fecha (25 de agosto de 2026 en la referencia del artículo base). Aun así, la cadena descrita combina varias piezas: exposición de API local, validación de cabeceras, CORS, y el uso de DNS rebinding.
Pasos de prevención recomendados por la lógica del ataque
Sin entrar en suposiciones no respaldadas, el propio contenido del reporte deja una dirección clara para reducir riesgo. Si la API de Ollama queda accesible más allá de loopback, se incrementa la superficie. Además, si el sistema depende de cabeceras que pueden saltarse en ciertas rutas, la mitigación debe ser consistente.
En la práctica, la protección se centra en validar correctamente Host y Origin del lado del servidor, evitando que una solicitud desde un origen controlado por un atacante sea aceptada como si fuera válida. También conviene revisar si el despliegue de NemoClaw/ Ollama cumple las recomendaciones de “no exponer” hacia redes externas, porque el ataque descrito no requiere que el usuario navegue desde otro equipo: basta con que el navegador llegue a la interfaz local.
Finalmente, revisa si tu instalación incorpora los cambios de seguridad referidos para Ollama (como los mencionados en v0.1.29 y asesorías asociadas), y asegúrate de ejecutar el componente bajo configuraciones que no abran el puerto sin los controles esperados.
Conclusión
El informe de Oasis Security advierte que NVIDIA NemoClaw puede enfrentar un riesgo serio cuando su forma de iniciar Ollama termina habilitando una vía para modificar la chat template. Si un atacante logra esa modificación mediante una página web controlada y técnicas como DNS rebinding, el envenenamiento del modelo podría persistir y afectar conversaciones posteriores.
Aunque no se dispone de un CVE ni de un rango de versiones afectadas en el material descrito, el mensaje para operadores es claro: el modo de enlazar (bind) y la validación de cabeceras en la API importan tanto como el componente “sandbox” que se use alrededor del agente. Revisar la configuración y mantener Ollama actualizado con correcciones relevantes puede reducir de forma significativa el riesgo de NemoClaw envenenar modelo.
Fuente: https://thehackernews.com/2026/08/a-malicious-webpage-could-poison-your.html
