NVIDIA NemoClaw Vulnerability Exposes AI Agents to Hidden Instruction Injection
A newly disclosed vulnerability in **NVIDIA NemoClaw**, reported by **Oasis Security**, could allow attacker-controlled webpages to gain unauthenticated control over local **Ollama** instances. This critical flaw enables the injection of hidden instructions directly into AI models, potentially compromising their behavior without detection. While a partial fix exists for macOS and Linux, Windows and WSL installations remain vulnerable.
Cybersecurity firm **Oasis Security** has unveiled a significant vulnerability within **NVIDIA NemoClaw**, an open-source reference stack for running AI agents like **OpenClaw**. The flaw could permit a malicious webpage to seize unauthenticated control of a local **Ollama** instance, which serves as an inference backend for **NemoClaw**, and embed covert instructions directly into the AI model.
The findings were shared with NVIDIA's Product Security Incident Response Team (**PSIRT**) prior to public disclosure. As of August 25, 2026, no exploitation of this vulnerability has been reported, and it does not yet carry a **CVE** identifier.
### Platform-Specific Vulnerabilities
**Elad Luz**, Head of Research at Oasis Security, confirmed that **NemoClaw v0.0.35** addresses the issue on macOS and Linux platforms. However, the vulnerability persists for Windows and WSL (Windows Subsystem for Linux) installations, where **v0.0.34** introduced a Windows installer that includes a warning instead of a fix.
### The Root Cause: Exposed Ollama Instances
The core of the problem lies in how **NemoClaw** configures **Ollama**. On vulnerable platforms, **Ollama** is started with `OLLAMA_HOST=0.0.0.0:11434`, binding the model server to all network interfaces. This configuration exposes the **Ollama API** without authentication, allowing an attacker to modify the model's chat template. Such modifications can inject hidden instructions that apply to every subsequent conversation, effectively poisoning the model's behavior.
"Sandboxing protects the endpoint, but taking over the agent takes over its access and tools," Oasis Security highlighted in their report.
**NVIDIA's** own documentation for **Ollama** setup and the current source code indicate varying **Ollama** handling across platforms:
* **Non-WSL hosts:** **Ollama** typically runs on `127.0.0.1:11434` behind a token-gated reverse proxy on `0.0.0.0:11435`.
* **Docker Desktop on WSL:** The proxy is bypassed as containers access the host's loopback via `host.docker.internal`.
* **Windows-host Ollama path:** This path sets `OLLAMA_HOST=0.0.0.0:11434` to enable Docker Desktop container access, critically without requiring authentication on port 11434.
**Ollama's** own integration page for **NemoClaw** also advises setting `OLLAMA_HOST=0.0.0.0` when operating within WSL2 or a container. Binding to `0.0.0.0` has previously been identified as a vector that exposes **Ollama** instances beyond the local machine.
### Bypassing Security Measures with DNS Rebinding
The **Ollama API** on port 11434 lacks authentication and relies on two middleware layers to block browser-originated requests. However, when the bind address is not loopback, the Host header check is entirely skipped. The Cross-Origin Resource Sharing (**CORS**) layer then treats the request as same-origin, permitting it, especially if the Origin and Host headers both carry the attacker's domain.
**DNS rebinding** is the technique that closes this gap. An attacker's domain first resolves to their server and then to `127.0.0.1`, while the browser continues to consider the requests as same-origin. This full attack chain was successfully tested on macOS using Firefox against a vulnerable **NemoClaw** version, according to Luz. Validating Host and Origin headers is the standard countermeasure for this class of attack.
Notably, **DNS rebinding** against **Ollama's API** has been documented before. **Ollama** released a fix in **v0.1.29** on March 14, 2024, and **NCC Group** published an advisory (**CVE-2024-28224**) the following month, recommending server-side Host header validation.
"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," Luz explained.
### The Payload: Persistent Model Poisoning
With the API reachable, the reported exploit leverages the `/api/create` endpoint to write a modified Go template. This template dictates how structured message arrays are rendered into raw text before being processed by the model. The poisoned version appends attacker-controlled text to every system message during inference, making these hidden instructions persistent across conversations and resistant to the agent's own system prompts.
"The client cannot detect or prevent this - the template is a model-level property invisible to API consumers," Oasis Security stated.
### Incomplete Mitigation Efforts
A review of the **NemoClaw** repository at commit `17f0ca3b` on August 25 revealed that the local **Ollama** proxy in **v0.0.106** (introduced August 10) now refuses to start if the backend is not bound to loopback. This check, however, can be overridden by setting `NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1` and does not apply to WSL paths, including the vulnerable Windows-host configuration where the `0.0.0.0` binding is set.
Furthermore, no integrity check for chat templates was found in the repository. **NemoClaw** only queries **Ollama's** `/api/show` endpoint for context length and tool-calling capabilities.
While **NVIDIA's** documentation advises against exposing port 11434 to a LAN or the internet on the Windows-host path, this guidance addresses network-level inbound access. The **DNS rebinding** attack chain bypasses this, as the browser making the requests is already on the host and reaches the daemon at `127.0.0.1`.
This technique of poisoning model chat templates for instruction injection has been documented previously, notably against **Paperclip** and **OpenClaw** agents, using similar browser-to-localhost attack paths.
