Oasis Security has disclosed a weakness in NVIDIA NemoClaw that could let an attacker-controlled webpage take unauthenticated control of the local Ollama instance serving an AI agent and plant hidden instructions inside the model itself.
The findings were shared with The Hacker News ahead of publication, and the report says Oasis Security reported them to NVIDIA’s Product Security Incident Response Team (PSIRT) beforehand. The research carries no CVE identifier. No exploitation has been reported as of August 25, 2026.
Oasis Security’s head of research, Elad Luz, told The Hacker News that NemoClaw v0.0.35 fixed the issue on macOS and Linux. There is no fix on the Windows and WSL path, according to Luz, where v0.0.34 added a Windows installation that carries a warning instead.
NemoClaw is NVIDIA’s open source reference stack for running agents such as OpenClaw inside its OpenShell sandboxes, and Ollama is one of its supported local inference backends.
The report describes NemoClaw starting Ollama with OLLAMA_HOST=0.0.0.0:11434, binding the model server to every network interface, and says the resulting API access allows an attacker to modify the model’s chat template so that hidden instructions are applied to every later conversation.
“Sandboxing protects the endpoint, but taking over the agent takes over its access and tools,” Oasis Security said in the report.
NVIDIA’s own Ollama setup documentation and the current source place that binding on one platform path. NemoClaw’s Ollama handling differs by platform –
- Non-WSL hosts keep Ollama on
127.0.0.1:11434behind a token-gated reverse proxy on0.0.0.0:11435, and onboarding restarts a daemon already bound elsewhere back to loopback. - Docker Desktop on WSL skips the proxy, because the container reaches the host’s loopback address through
host.docker.internal. - The Windows-host Ollama path sets
OLLAMA_HOST=0.0.0.0:11434so Docker Desktop containers can reach the daemon, and does not require authentication on port 11434.
Ollama’s own NemoClaw integration page also advises setting OLLAMA_HOST=0.0.0.0 when running inside WSL2 or a container, and binding it to 0.0.0.0 has previously been identified as the change that exposes Ollama instances beyond the local machine.
The API on port 11434 has no authentication and relies on two middleware layers to block browser-originated requests. When the bind address is not loopback, the Host header check is skipped entirely. The Cross-Origin Resource Sharing (CORS) layer then treats the request as same-origin and allows it, because the Origin and Host headers both carry the attacker’s own domain. That holds for a page the attacker serves on port 11434.
Domain Name System (DNS) rebinding closes the gap, with the attacker’s domain resolving first to their own server and then to 127.0.0.1 while the browser continues to treat the requests as same-origin.
Luz said the full chain was tested on macOS with Firefox against a vulnerable NemoClaw version. Verifying Host and Origin headers is the standard fix for that class of attack.
DNS rebinding against Ollama’s API is itself documented. Ollama shipped a fix in v0.1.29 on March 14, 2024, and NCC Group published the advisory as CVE-2024-28224 the following month. That advisory recommended validating the Host header on the server side to allow only a set of authorized values.
Ollama introduced that validation in response to the 2024 disclosure, according to Luz.
“But Ollama skips that validation whenever it is bound to a non-loopback address, and 0.0.0.0 is exactly how NemoClaw configures it,” he said.
With the API reachable, the report’s payload writes a modified Go template through /api/create. The template controls how the structured messages array is rendered into raw text before the model processes it, and the poisoned version appends attacker-controlled text to every system message at inference time.
Instructions planted this way persist across later conversations and survive the agent supplying its own system prompt, according to the report.
“The client cannot detect or prevent this – the template is a model-level property invisible to API consumers,” Oasis Security said.
The Hacker News reviewed the NemoClaw repository at commit 17f0ca3b on August 25 and found that the local Ollama proxy refuses to start against a backend that is not bound to loopback, a default introduced in v0.0.106 on August 10. The proxy exits with a dedicated status code and prints:
“Refusing to start: an Ollama daemon reachable on a non-loopback interface bypasses the proxy’s token check entirely. Set OLLAMA_HOST=127.0.0.1:${port} on the Ollama systemd unit or set NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 to override (not recommended).”
That check can be switched off by setting NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1, and it does not fail closed on hosts where the bind check cannot run.
The check runs inside the proxy itself. NemoClaw does not start that proxy on the WSL paths, and the Windows-host configuration is one of them. The v0.0.106 default therefore does not reach the platform path where the 0.0.0.0 binding is set.
The same review found no chat-template integrity check anywhere in the repository, with NemoClaw querying Ollama’s /api/show endpoint only for a model’s native context length and its declared tool-calling capability.
NVIDIA’s documentation instructs operators on the Windows-host path not to expose port 11434 to a LAN or the internet. That guidance addresses inbound access from the network. The rebinding chain does not need it, because the browser making the requests is already running on the host and reaches the daemon at 127.0.0.1.
Poisoning a model’s chat template so that instructions run during inference has been documented before as poisoned chat templates. Oasis Security researchers documented the same technique against Paperclip earlier this month, and used a comparable browser-to-localhost path to hijack local OpenClaw agents in February.
