The convenience default that opened the door
The root cause is a configuration choice that trades security for convenience, a pattern familiar to anyone who has audited a rushed local AI deployment shipped ahead of a product launch deadline. NemoClaw configures Ollama, the local inference backend it runs on top of, with OLLAMA_HOST set to 0.0.0.0:11434 rather than binding to loopback only. That setting exposes the Ollama API across every network interface on the machine instead of restricting it to the local device alone, and the API listening at port 11434 ships with no authentication layer sitting in front of it to gate who can send it commands.
On its own, that misconfiguration is a familiar local-network risk, the kind that matters mainly if an attacker already has a foothold somewhere on the same network segment as the victim machine. Oasis Security's research, led by head of research Elad Luz, found a path that removes even that precondition entirely, turning a local network exposure that once required proximity into something a completely remote, unauthenticated webpage can reach from anywhere on the open internet with no prior access needed at all.
DNS rebinding turns a browser tab into a network attacker
DNS rebinding is an old technique getting new relevance from the current local-AI boom sweeping through developer tooling. A malicious webpage's DNS record initially resolves to an address the attacker controls, passing the browser's same-origin checks cleanly on first load, then the attacker rapidly re-points that same domain to a local address, in this case the machine's own loopback or LAN interface where Ollama happens to be listening. The browser, still treating the domain as the same origin it already validated moments earlier, lets follow-up requests through as if they were ordinary same-origin traffic, when in reality they are now hitting a service running quietly on the victim's own machine.
Against NemoClaw's exposed Ollama instance, that means a user simply visiting a malicious page is enough on its own, no click required beyond the initial page load, no download, no explicit action beyond the browser rendering the content it was served. The result can be the browser issuing requests directly to the local Ollama API without the user ever knowing a network request left their machine. From there the attacker has an open, unauthenticated door into a service that was never designed to be reachable from the open web in the first place, sitting exposed purely because of a default the packaging never questioned.
Poisoning that survives every future conversation
Once inside, the attack path used the /api/create endpoint to write a modified Go template, the mechanism Ollama relies on to structure how prompts and responses get assembled before reaching the model. By appending hidden instructions to that template, an attacker embeds content that gets silently prepended to every system message the model receives from that point forward, indefinitely. The model itself has no way to distinguish the injected instruction from a legitimate one baked in at setup, because both arrive through the exact same template mechanism it was built to trust without question.
The persistence is what separates this from a typical single-session prompt injection that resets once the conversation ends. Oasis Security's finding is that these poisoned instructions persist across all subsequent conversations and cannot be detected by API consumers downstream of the compromised instance. An application built on top of that Ollama instance, or an agent framework calling into it for tool use and task execution, inherits the poisoned behavior indefinitely, with no signal anywhere in the API response that anything has been quietly altered underneath it.
Why agents make this worse than a chatbot problem
Oasis Security's framing of the stakes cuts to why this matters well beyond a single poisoned chatbot response embarrassing a user in a chat window: "Sandboxing protects the endpoint, but taking over the agent takes over its access and tools." NemoClaw is increasingly used to power OpenClaw agents running inside OpenShell sandboxes, deployments where the model handles far more than generating text for a human to read. It calls tools, executes commands, and takes concrete actions with real permissions on behalf of the user or the enterprise system it has been embedded into.
A sandbox that isolates the agent's execution environment on the host machine does very little to protect against an agent whose underlying instructions have already been quietly rewritten before it ever begins to run. The sandbox constrains what the agent process can physically touch on the machine it runs on. The compromised template instead controls what the agent believes its job actually is, and that belief is exactly what this vulnerability lets an attacker set from a webpage with no authentication required at any point in the chain.
A partial fix, and a Windows gap that stays open
NVIDIA shipped a fix for macOS and Linux in NemoClaw version 0.0.106 on August 10, 2026, closing the exposure on those two platforms by binding the local proxy correctly. Windows and WSL deployments remain vulnerable today, a gap made more notable by the fact that an earlier release, version 0.0.34, added only a warning message about the risk rather than closing the exposure outright on that platform. A more recent mitigation, landed as commit 17f0ca3b on August 25, 2026, has the local Ollama proxy refuse to start against non-loopback backends by default, though that protection does not extend to WSL paths where the underlying binding issue still persists unaddressed.
No CVE identifier has been assigned to this issue as of publication, which will keep it off standard vulnerability scanning feeds and CISA KEV monitoring despite the real severity of what it quietly enables inside an enterprise environment. Enterprises running NemoClaw or any Ollama-backed local AI tooling on Windows should treat OLLAMA_HOST binding as a configuration item to audit directly today rather than waiting on a CVE to eventually trigger the usual patch management workflow, and should restrict outbound access from any host running local inference services until the Windows and WSL fix actually ships.
