A weakness in NVIDIA NemoClaw lets an attacker-controlled web page take unauthenticated control of the local Ollama instance behind an AI agent and implant hidden instructions inside the model itself, according to Oasis Security. The flaw carries no CVE identifier and, as of August 25, 2026, no exploitation has been reported. Oasis Security disclosed it to NVIDIA's PSIRT before publication. NemoClaw v0.0.35 fixes the issue on macOS and Linux; there is no fix on the Windows and WSL path, where v0.0.34 added a Windows installation that ships a warning instead.

NemoClaw is NVIDIA's open source reference stack for running agents such as OpenClaw inside its OpenShell sandboxes, with Ollama as one supported local inference backend. The problem starts with how some paths launch the model server: NemoClaw can start Ollama with OLLAMA_HOST=0.0.0.0:11434, binding it to every network interface with no authentication on that port. Oasis Security's head of research, Elad Luz, tested the full chain on macOS with Firefox against a vulnerable build. The takeaway matters for anyone treating the sandbox as the security boundary: as the researchers put it, sandboxing protects the endpoint, but taking over the agent takes over its access and tools.

How can a web page reach a model running on my own machine?

The Ollama API on port 11434 has no authentication and leans on two middleware layers to block browser-originated requests, and both can be sidestepped. When the bind address is not loopback, the Host header check is skipped entirely. The 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 for a page served on port 11434. DNS rebinding closes the remaining gap: the attacker's domain resolves first to their own server, then to 127.0.0.1, while the browser keeps treating the requests as same-origin. From there an attacker can modify the model's chat template so hidden instructions are applied to every later conversation, a persistent poisoning of the agent rather than a one-off prompt injection.

Which NemoClaw setups are affected?

Platform handling differs, and that is the crux. Non-WSL hosts keep Ollama on 127.0.0.1:11434 behind a token-gated reverse proxy on 0.0.0.0:11435, and onboarding restarts a stray daemon back to loopback. Docker Desktop on WSL skips that proxy because the container reaches the host loopback through host.docker.internal, and the Windows-host path sets OLLAMA_HOST=0.0.0.0:11434 without authentication so containers can reach the daemon.

Our read

This is the AI-agent version of a lesson defenders keep relearning: a boundary that only guards the process does nothing for the credentials and tools the process holds. Verifying Host and Origin headers, and rejecting rebinding, is the standard fix for this class of attack, and keeping Ollama on loopback removes the exposure outright. The broader point ties to how we think about supervised adversary simulation. Agent stacks now bundle a local model server, a browser-reachable API, and privileged tooling into one trust domain, so the useful question is not "is the sandbox intact" but "what happens once the agent inside it is told what to do by an outsider." On the Windows and WSL path, where no fix exists yet, treat any agent with network-bound local inference as reachable and pin it to loopback yourself.

Reporting by The Hacker News; technical detail per Oasis Security's disclosure to NVIDIA PSIRT. Sources linked above.

Related: Prompt injection and AI-agent risk and Nexus Void adversary simulation.