Researchers from Oasis Security have disclosed a risk that could enable Malicious Webpage Poisoning of a local AI setup built around NVIDIA NemoClaw and Ollama. In short: an attacker-controlled webpage may be able to take unauthenticated control of the local Ollama instance that serves an agent, then plant hidden instructions directly into the model via its chat template.
At the time of the disclosure (August 25, 2026), the report did not include a CVE identifier, an affected version range, or a confirmed patched release. That means operators currently have no clear checklist to determine whether their specific installation is in scope.
What NemoClaw and Ollama are used for
NVIDIA NemoClaw is presented as an open source reference stack for running agents—such as OpenClaw—inside OpenShell sandboxes. Ollama is one of the supported local inference backends that NemoClaw can use to run models locally.
The core of the issue is not remote model download or a “cloud” takeover. Instead, the attacker’s goal is to abuse how the local Ollama service is exposed on the network so it can be manipulated from a browser context running on the same machine.
The attack path: from webpage to model-level instructions
The report describes NemoClaw starting Ollama in a way that binds the model server to all network interfaces, specifically with OLLAMA_HOST=0.0.0.0:11434. When Ollama is reachable this way, an attacker can modify the model’s chat template so that hidden instructions are applied to later conversations.
Oasis Security summarizes the practical consequence with a key point: while sandboxing may protect the endpoint, taking over the agent also means taking over its access and tools. If the chat template is poisoned, the model can begin executing attacker-controlled instructions during inference, even if the agent later supplies its own system prompt.
Why binding to 0.0.0.0 matters
According to the disclosure, the behavior differs by platform. The report highlights several configuration paths:
- Non-WSL hosts: Ollama is kept on 127.0.0.1:11434 behind a token-gated reverse proxy on 0.0.0.0:11435. During onboarding, a daemon already bound elsewhere is restarted back to loopback.
- Docker Desktop on WSL: the proxy is skipped, because the container reaches the host loopback address via host.docker.internal.
- Windows-host path: Ollama sets OLLAMA_HOST=0.0.0.0:11434 so that Docker Desktop containers can reach the daemon. In this path, the report notes that authentication is not required on port 11434.
Ollama’s own NemoClaw integration guidance also advises setting OLLAMA_HOST=0.0.0.0 when running inside WSL2 or a container. But, as the disclosure notes, exposing Ollama on 0.0.0.0 has previously been identified as the change that can make local services reachable beyond the machine.
How unauthenticated access is allegedly achieved
A major part of the described chain involves web-origin controls. The report says the Ollama API on port 11434 has no authentication and relies on two middleware layers intended to block browser-originated requests.
However, the report states that when the binding address is not loopback, the Host header check is skipped. Then the CORS layer may treat the request as same-origin because both the Origin and Host headers contain the attacker’s domain.
Under that model, a browser page served by the attacker can make requests that the local service mistakenly accepts. The disclosure further describes DNS rebinding as the mechanism that closes the remaining gap: the attacker’s domain resolves first to the attacker-controlled server, then switches to 127.0.0.1 while the browser continues treating the requests as same-origin.
Importantly, the report does not specify which browsers or operating systems the chain was verified against. Still, it notes that validating Host and Origin headers is the standard server-side mitigation for this class of DNS rebinding attack.
Related precedent: Ollama’s earlier fix
DNS rebinding against Ollama’s API has been documented before. The disclosure points out that Ollama shipped a fix in v0.1.29 on March 14, 2024, and that NCC Group published an advisory the next month as CVE-2024-28224.
That advisory recommended validating the Host header on the server side to allow only authorized values. The NemoClaw-related report suggests the described exploit chain depends on the Host header check being bypassed in certain binding scenarios.
Model poisoning details: the chat template
Once the API is reachable, the report says the payload writes a modified Go template through /api/create. This template determines how the structured messages array is rendered into raw text before the model processes it.
The poisoned template reportedly appends attacker-controlled text to every system message at inference time. Because it changes how future conversations are rendered, the modification can persist across later interactions and survive attempts by the agent to provide its own system prompt.
The disclosure includes a blunt assessment from Oasis Security: the client cannot detect or prevent this, because the template is treated as a model-level property that API consumers cannot easily observe.
What reviewers found in NemoClaw’s repository
The Hacker News reviewed the NemoClaw repository at commit 17f0ca3b on August 25, 2026. The review reportedly found a local proxy behavior designed to avoid the dangerous exposure scenario.
Specifically, the proxy refuses to start if the Ollama backend is reachable on a non-loopback interface. The report describes the default introduced in v0.0.106 on August 10, and notes that the proxy exits with a dedicated status code and a message instructing operators to set OLLAMA_HOST=127.0.0.1:${port} on the systemd unit.
The report also mentions an override environment variable, NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1, though it is described as not recommended. It further states that the check does not fail closed on hosts where the bind check cannot run, and that it also runs inside the proxy itself.
Additionally, the disclosure says NemoClaw does not start the local proxy in certain WSL paths, and that the Windows-host configuration is among the paths where the proxy logic may not apply. This would explain why the v0.0.106 default might not cover the platform route where 0.0.0.0 is configured.
Missing template integrity checks
The review mentioned in the disclosure found no chat-template integrity verification anywhere in the repository. Instead, NemoClaw appears to query Ollama’s /api/show endpoint mainly to obtain a model’s native context length and its declared tool-calling capability.
That means there is no described mechanism that would detect a previously poisoned template or prevent the poisoned template from being used at inference time.
Operator guidance and why network exposure guidance may not fully help
NVIDIA’s documentation for the Windows-host path reportedly instructs operators not to expose port 11434 to a LAN or the internet. That guidance addresses inbound network access from other devices.
The report emphasizes a different angle: this chain does not necessarily require external reachability. The browser is already running on the host, and DNS rebinding can redirect the browser traffic to 127.0.0.1—so the attack focuses on local access control rather than broad inbound exposure.
Why this technique matters beyond NemoClaw
The disclosure notes that poisoning chat templates so instructions run during inference has been seen before. Oasis Security researchers reportedly documented similar technique work against “Paperclip” earlier in the month, using a comparable browser-to-localhost approach to hijack local OpenClaw agents.
The theme is consistent across these reports: when local agent runtimes expose an API without robust server-side defenses against rebinding and header spoofing, a hostile webpage can potentially alter the model’s behavior in ways the user interface cannot easily reveal.
Current status: no CVE, no confirmed affected versions
Oasis Security shared the findings with NVIDIA’s Product Security Incident Response Team (PSIRT) before publication. However, the disclosure provides no CVE ID, no affected version range, and no patched version. As of August 25, 2026, no exploitation was reported in the public write-up.
The Hacker News also reports that it reached out to Oasis Security for NemoClaw version and platform path details relevant to the proof of concept, with an intention to update if NVIDIA or the researchers provide additional information.
Conclusion: reduce local exposure and harden header validation
Malicious Webpage Poisoning in this context is a reminder that “local-only” AI deployments can still be attacked through the browser when service binding, CORS, and header checks don’t fully account for DNS rebinding.
Until a clear affected version and fix path is provided, operators should treat any configuration that binds local Ollama endpoints broadly (such as 0.0.0.0) and any reliance on token or proxy layers as areas that need careful review. The most important defensive principle described in the report remains the same: validate request context on the server by enforcing strict checks of Host and Origin, not only via middleware that can be bypassed by binding behavior.
Source: https://thehackernews.com/2026/08/a-malicious-webpage-could-poison-your.html
