Security Vulnerability Lets Malicious Webpages Poison Local AI Models Behind NVIDIA NemoClaw

A Malicious Webpage Could Poison Your Local AI Model Behind NVIDIA NemoClaw

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. However, it carry no CVE identifier, no affected version range, and no patched version, so an operator running NemoClaw cannot currently check whether their installation is in scope. No exploitation has been reported as of August 25, 2026. 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 , 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 behind a token-gated reverse proxy on , 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 . * The Windows-host Ollama path sets so Docker Desktop containers can reach the daemon, and does not require authentication on port 11434. Ollama's own NemoClaw integration page also advises setting 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 while the browser continues to treat the requests as same-origin. The report does not state which browsers or operating systems the chain was verified against. 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. With the API reachable, the report's payload writes a modified Go template through . 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 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 , and it does not fail closed on hosts where the bind check cannot run. The check also 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 binding is set. The same review found no chat-template integrity check anywhere in the repository, with NemoClaw querying Ollama's 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 . 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. The Hacker News has reached out to Oasis Security for the NemoClaw version and platform path the proof of concept was verified against, and will update this story with any response.

Nvidia NemoClaw flaw let attackers poison the model behind a developer's AI agent

Nvidia NemoClaw flaw let attackers poison the model behind a developer's AI agent Researchers at nonhuman identity security company Oasis Security Ltd. today disclosed a vulnerability in Nvidia Corp.'s NemoClaw that hands an attacker full control of the local model server powering a developer's AI agent. The vulnerability, tracked as CVE-2026-65105, can be triggered by one visit to a malicious website. Oasis reported it to Nvidia's Product Security Incident Response Team before publishing. The research is also the first from the team since Cyera Inc. agreed in July to buy Oasis for a reported $1 billion. Nvidia released NemoClaw at its GTC conference in March as a safer way to run agents such as OpenClaw. The agent sits inside an OpenShell sandbox, which fences off the file system, the network and the processes it can touch. NemoClaw can run the agent's model locally through Ollama instead of calling out to a cloud service. Ollama is the server an attacker ends up controlling. Reaching it from inside the sandbox takes some work. Docker containers have no path to 127.0.0.1, and that's where Ollama binds out of the box. NemoClaw launches Ollama with the flag OLLAMA_HOST=0.0.0.0:11434. Port 11434 goes live on every interface. Other devices on the same network segment can hit it too, and the install message still reads localhost:11434. Ollama's application programming interface has no authentication. Two middleware checks stand in for it, an origin allowlist and validation of the Host header. The researchers found the Host check is skipped entirely whenever the bind address is not loopback. That leaves the origin check, and DNS rebinding walks around it. An attacker points a domain they control at their own server and serves the victim a page on port 11434. The domain then re-resolves to 127.0.0.1. Same-origin policy keys on the hostname, not the address behind it, and the browser does not object. Requests from the page land on the Ollama instance running on the victim's machine. Full API access alone lets an attacker enumerate what is installed, lift the machine's hostname and public key or delete models outright. Model poisoning is the one Oasis considers worst. Injecting a hidden system prompt into the model does not survive contact with the agent, because OpenClaw sends its own system prompt and that overrides the one baked in. So the researchers went a layer lower. Ollama's /api/create endpoint also accepts a template field. The value is a Go template, and it renders the message list into the raw text the model reads. An attacker can pull the the model's existing template through /api/show, splice an instruction into it and write it back. Every message the client sends then passes through the attacker's version, including the agent's own system prompt, which reaches the model with the hidden instruction appended. From the outside nothing looks wrong. Name, size and metadata all read as normal. Opening a fresh chat clears nothing. The payload lives in the model definition, well below the conversation state an operator can reset. An instruction sitting in that position can tell the agent to write vulnerabilities into code that passes casual review, to stay quiet about security problems or to push conversation contents to an outside endpoint. Elad Luz, head of research at Oasis, said the change sits "one layer beneath anything a guardrail or an operator can see" and leaves an integrity problem that is very hard to detect. The sandbox does not help much, he said, because the blast radius of an AI system is its authorizations rather than its isolation. A video published alongside the paper walks through the full chain, from malicious website to a poisoned agent answering with the attacker's marker. Discussing the report, Randolph Barr, chief information security officer at API security and bot management provider Cequence Security Inc., said the target matters more here than the technique. "The individual pieces here aren't new, DNS rebinding's been a browser party trick for over a decade but pointing it at an unauthenticated local model server is the new part, and it's a good preview of where agentic AI risk actually lives," Barr said in commentary provided to SiliconANGLE. "It's not really in the model; it's in the plumbing around it. Sandboxing the agent doesn't buy you much if the thing it's built on top of is reachable from any tab in the browser." Collin Hogue-Spears, senior director of solution management at application security testing company Black Duck Software Inc., noted that Ollama hardened this class of browser-to-local-service exposure back in 2024 under CVE-2024-28224. NemoClaw's current design refuses a non-loopback Ollama backend on covered topologies, he said. Anyone still on the older pattern should keep Ollama on loopback behind an authenticated proxy and check the Host header against an allowlist. "Local describes where the model runs," Hogue-Spears added. "Private describes who can reach it."