Oasis Security has disclosed a vulnerability in NVIDIA NemoClaw that allows an attacker-controlled webpage to take unauthenticated control of a local Ollama instance serving an AI agent. The attack vector involves a malicious webpage that can plant hidden instructions inside the AI model itself, effectively poisoning it. The vulnerability requires no authentication to exploit, making it particularly dangerous for users running local AI models via Ollama. Oasis Security responsibly disclosed the findings to NVIDIA's Product Security Incident Response Team prior to publication. The issue highlights emerging security risks associated with locally hosted AI inference systems and agent frameworks. The attack could enable persistent manipulation of AI model behavior through hidden prompt injection or instruction poisoning techniques.
NVIDIA NemoClaw starts Ollama with OLLAMA_HOST=0.0.0.0:11434 on the Windows-host path, binding the model server to all network interfaces without authentication on port 11434. The Ollama API relies on two middleware layers to block browser-originated requests: a Host header check and a CORS layer. When bound to a non-loopback address (0.0.0.0), the Host header check is skipped entirely, and the CORS layer treats requests as same-origin when the Origin and Host headers both carry the attacker's domain. A DNS rebinding attack further exploits this by having the attacker's domain first resolve to their own server and then to 127.0.0.1, while the browser continues treating requests as same-origin. This allows an attacker-controlled webpage to reach the unauthenticated Ollama API and use the /api/create endpoint to write a malicious Go chat template. The poisoned template appends attacker-controlled instructions to every system message at inference time, persisting across all subsequent conversations and surviving the agent's own system prompts. The poisoned template is invisible to API consumers as it is a model-level property. Platform behavior differs: non-WSL hosts keep Ollama on 127.0.0.1:11434 behind a token-gated reverse proxy; Docker Desktop on WSL skips the proxy using host.docker.internal; the Windows-host path sets OLLAMA_HOST=0.0.0.0:11434 without authentication. NemoClaw v0.0.106 introduced a proxy check that refuses to start against a non-loopback backend, but this check only runs inside the proxy, which is not started on WSL/Windows-host paths, leaving those configurations still vulnerable. No chat-template integrity check exists anywhere in the NemoClaw repository.
1. Upgrade NVIDIA NemoClaw to v0.0.35 or later on macOS and Linux to receive the fix. 2. On Windows and WSL paths, avoid exposing Ollama on port 11434 to any network interface beyond loopback; set OLLAMA_HOST=127.0.0.1:11434 where possible. 3. Do not expose port 11434 to a LAN or the internet per NVIDIA's documentation guidance. 4. Validate and enforce Host and Origin headers on the Ollama server side, allowing only authorized values. 5. Audit existing Ollama model chat templates for unexpected or unauthorized modifications via the /api/show endpoint. 6. Implement chat-template integrity checks to detect tampering. 7. Avoid setting NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 as this disables the bind probe safety check. 8. Ensure the NemoClaw local Ollama proxy (introduced in v0.0.106) is active and not bypassed, especially verifying it runs on all platform paths including WSL. 9. Use firewall rules to restrict access to port 11434 to loopback only. 10. Monitor for DNS rebinding attempts targeting localhost services.
Ollama bound to 0.0.0.0:11434 (non-loopback interface), Unexpected or modified chat templates retrieved via Ollama /api/show endpoint, Unauthenticated HTTP requests to port 11434 from non-loopback sources, POST requests to /api/create on Ollama API modifying chat templates, DNS rebinding activity targeting 127.0.0.1:11434
