NVIDIA NemoClaw Flaw Lets a Malicious Webpage Poison the Local AI Model, Oasis Security Says

Security researchers at Oasis Security say a single malicious webpage could quietly take over the local model server that powers an NVIDIA NemoClaw AI agent, then plant hidden instructions inside the model that survive from one conversation to the next. The target is Ollama, the local inference backend NemoClaw can run so an agent answers from the developer's own machine instead of a cloud API. Per the report, that model server's interface can be reached with no authentication, and whoever reaches it can change a model-level setting so every later conversation carries text the operator never wrote and cannot see.

Oasis Security disclosed the weakness on August 25, 2026, and says it reported the findings to NVIDIA PSIRT (Product Security Incident Response Team) before going public. As of that date, no exploitation had been reported. The research was shared with The Hacker News ahead of publication and separately covered by SiliconANGLE.

What Oasis Security Disclosed

NemoClaw is NVIDIA's open-source reference stack for running agents such as OpenClaw inside sandboxed environments, and Ollama is one of its supported local inference backends. The problem, according to the report, is not the sandbox but the plumbing underneath it. On one platform path, NemoClaw launches Ollama bound to every network interface (the setting OLLAMA_HOST=0.0.0.0:11434), and the model API listening on port 11434 requires no authentication. When the server is bound that broadly, a browser-origin check that would normally block cross-site requests is skipped, which is what opens the door to an attacker-controlled webpage.

The consequence Oasis Security flags as worst is not data theft but model poisoning. Rather than injecting a system prompt (which the agent overrides with its own), the technique alters the model's chat template, the layer that turns a conversation into the raw text the model reads. Modified once, it appends attacker-supplied text to the agent's own system message every time, so hidden instructions inside the model persist across new chats and are invisible to the client. "The client cannot detect or prevent this," Oasis Security said in the report, because "the template is a model-level property invisible to API consumers." The CyberSignal is pointing readers to the Oasis Security writeup and The Hacker News for the full technical walk-through rather than reproducing the chain here.

What that access buys an attacker is leverage over whatever the agent can touch. An agent wired into source control, cloud accounts, or a build pipeline hands its authorizations to whoever controls the model behind it. As Oasis Security put it, "Sandboxing protects the endpoint, but taking over the agent takes over its access and tools." Elad Luz, the firm's head of research, told SiliconANGLE the change sits "one layer beneath anything a guardrail or an operator can see," which is what makes it hard to detect.

Why a Local Model Server Is a Real Target

The individual moving parts here are old. Binding a local service to 0.0.0.0, skipped Host-header checks, and DNS rebinding to defeat the browser's same-origin rule are all well-documented techniques. Ollama itself patched a DNS-rebinding weakness in its API two years ago, shipped as CVE-2024-28224 in an NCC Group advisory. What is new is the target: pointing that decade-old browser trick at an unauthenticated local model server that an autonomous agent is built on top of.

That is the throughline defenders should sit with. As AI agents move onto the desktop and run their models locally for speed and privacy, they extend the browser-to-localhost attack surface that security teams have spent years trying to close. A model server on 127.0.0.1 feels private because it never leaves the machine, but "local" describes where the model runs, not who can reach it. Any tab the developer has open is a potential path to it. It is the same shape of problem The CyberSignal has tracked as researchers turn AI coding agents against the systems they touch, from guardrail bypasses across open-source coding agents to malicious skills on the OpenClaw marketplace and prompt injection reaching Google Gemini on Android. The trust boundary keeps landing in the same place: around the agent and everything it loads, not just the model.

Is There a CVE, and Has NVIDIA Patched It?

Here the reporting genuinely diverges, and defenders should not treat the specifics as settled. The Hacker News, working from the Oasis Security report, states plainly that the disclosure "carr[ies] no CVE identifier, no affected version range, and no patched version," which means an operator running NemoClaw cannot currently check whether their installation is in scope. SiliconANGLE, by contrast, cites CVE-2026-65105, though its own link resolves to a different identifier (CVE-2026-25651), so that number cannot be treated as confirmed. The CyberSignal could not independently verify any assigned CVE for this issue.

Patch status is similarly partial. Per The Hacker News's own review of the NemoClaw repository, a recent default refuses to start Ollama against a backend bound to a non-loopback interface, but that guard does not reach the Windows-host and WSL path where the 0.0.0.0 binding is set, and no chat-template integrity check exists in the codebase. In other words, the exposed path appears to remain exposed. Whether NVIDIA has shipped a complete fix is not confirmed. Until it says otherwise, defenders should assume the Windows-host and WSL topologies are still the ones to watch.

What Defenders Should Do Now

The defensive posture does not depend on the CVE question. It comes down to keeping the local model server off the browser's reach, confirming the NemoClaw build in use, and treating the served model as something whose integrity has to be verified rather than assumed. The checklist below is a same-week pass a security team can run against any host running NemoClaw with a local Ollama backend.

My read: The reported facts above are Oasis Security's; this is The CyberSignal's assessment, not a new finding. The headline risk is not NemoClaw specifically, it is the pattern. Local AI agents expand the browser-to-localhost attack surface, turning an unauthenticated model server into a high-value target that sits one tab away from a compromise. The agent's blast radius is its authorizations, not its isolation, so a sandbox that fences off the file system does little once the model behind the agent is the thing being rewritten. Expect more of this class as agents move on-device, and treat any local inference backend the way you would treat any other unauthenticated service on a developer's machine.

What Is Not Yet Confirmed

Several points remain open and should be read as unresolved. There is no CVE identifier The CyberSignal could verify (one outlet cites a number that conflicts with its own reference, and the primary reporting says none was assigned). Whether NVIDIA has issued a complete patch is not confirmed, and the Windows-host and WSL paths appear to remain exposed. It is not established whether other Ollama-served agents, beyond NemoClaw, are affected by the same configuration. No victims have been named, and while a demonstration was referenced alongside the research, The CyberSignal has not confirmed the release of a public proof-of-concept exploit. We will update this story as NVIDIA and Oasis Security publish more detail.

Primary Documents

• Oasis Security — the research team that disclosed the NemoClaw weakness and reported it to NVIDIA PSIRT.
• The Hacker News — report received ahead of publication, including the note that no CVE or patched version was published.
• SiliconANGLE — additional coverage with commentary from Oasis Security's head of research.
• NCC Group — the 2024 Ollama DNS-rebinding advisory (CVE-2024-28224) that establishes the prior art.