NemoClaw's DNS-Rebinding Flaw: One Webpage, Full Control of an Agent's Model

A single malicious webpage could rewrite the model backing a local AI agent — permanently, and without a single click beyond the visit itself. That is the practical result of a flaw NVIDIA's NemoClaw stack shipped by default: an unauthenticated local inference server, reachable from the browser, with an API that lets anyone who reaches it rewrite what the model believes its instructions are.

What the flaw is, in one paragraph

NVIDIA NemoClaw — an open-source reference stack for running agents such as OpenClaw inside OpenShell sandboxes — started a local Ollama instance bound to 0.0.0.0:11434 with no authentication (The Hacker News, as of 25 August 2026). Binding to 0.0.0.0 instead of the loopback address 127.0.0.1 means the server accepts connections from any process that can reach that port, not just processes on the same machine acting as the local user. Combined with DNS rebinding, that binding choice turns a background service meant to be a private, local convenience into a target a remote attacker's webpage can reach and manipulate.

Why a local server on 0.0.0.0 is browser-reachable — DNS rebinding in plain terms

Browsers normally stop a public webpage from calling a private IP address like 127.0.0.1 or an internal network address, because the same-origin model and modern private-network protections are built to block exactly that. DNS rebinding is the technique that defeats it.

Here is the mechanics in plain terms. An attacker controls a domain and its DNS record. When the victim's browser first resolves that domain, it gets a normal public IP address, and the page loads without triggering any private-network warning. After the page has loaded and the browser has cached that the origin is "safe," the attacker changes the DNS record for the same domain to point at 127.0.0.1 or the machine's local address — well within the DNS record's stated time-to-live, or exploiting how aggressively browsers re-resolve. The next request the page makes, still under the same origin the browser already trusts, now actually lands on the victim's own machine. The browser's origin check passed because the origin never changed on paper; only where that origin resolves changed underneath it.

Because Ollama was listening on 0.0.0.0:11434 with no authentication, the rebound request reaches a live, fully functional model-management API. No credential is required. No browser warning fires, because from the browser's point of view this looks like an ordinary request to an already-trusted origin.

From reachable to persistent: rewriting the model's chat template

Reachability alone is bad — it lets an attacker enumerate installed models and query the server. The escalation that makes this flaw serious is Ollama's /api/create endpoint, which NemoClaw's rebindable server also exposed. That endpoint can create or overwrite a model definition, including its chat template — the wrapper text that gets prepended to every conversation before the user's actual message reaches the model (The Hacker News, as of 25 August 2026).

An attacker who reaches /api/create through the DNS-rebinding path can overwrite the victim's local model's chat template with hidden instructions of the attacker's choosing. From that point forward, every conversation the victim has with that model runs through the poisoned template first — invisibly, since chat templates operate below the level of anything the user or the agent's own system prompt controls.

Why the poisoning survives your own system prompt

A model's chat template sits structurally underneath the system prompt in the request pipeline — it is the scaffolding the system prompt gets inserted into, not content the system prompt can review or override. Cyera's research on the technique describes the planted instructions as persisting across every future conversation and surviving even when the agent supplies its own system prompt (Cyera research, as of 25 August 2026). Rewriting the system prompt, switching agent frameworks on top of the same model, or restarting the agent process all leave the poisoned template untouched, because none of those actions touch where the template itself lives on disk.

This is the same class of persistence problem the site has already covered for other local-serving contexts, but the delivery mechanism here is distinct: no file needs to be dropped on the victim's machine by any other means, and no supply-chain component needs to be compromised. A single webpage visit is the entire attack (The Hacker News, as of 25 August 2026).

Patch status as of late August 2026

Patch coverage differs sharply by platform, and the gap matters for anyone still running NemoClaw on Windows.

The Hacker News reports that macOS and Linux received a real fix in NemoClaw v0.0.35, while the Windows/WSL path only shipped a warning in v0.0.34 — a notice, not a change in default behavior (The Hacker News, as of 25 August 2026). A separate, later mitigation in v0.0.106+ makes the stack refuse to start at all if it detects Ollama bound to a non-loopback address, which is a stronger control than a warning, but do not assume it is present just because you are running a recent version — verify the actual version and binding rather than trusting the platform label. As of the source date, no CVE had been assigned and no active exploitation had been reported (The Hacker News, as of 25 August 2026). Treat "unpatched on Windows/WSL" as the current state, not a temporary gap, until you have independently confirmed a fix on your own install.

What to check on any host running a local model backend

Whether or not you run NemoClaw specifically, the same misconfiguration class shows up anywhere a local model-serving process is bound wider than it needs to be. Work through this in order on any host running a local inference backend:

1. Identify every local model-serving process (Ollama, or any equivalent local inference server) running on the host, including ones started automatically by an agent framework you did not configure directly.
2. Check the bind address, not just whether a port is "open." A process listening on 127.0.0.1 is not reachable by DNS rebinding; one listening on 0.0.0.0 or a specific non-loopback interface is.
3. Confirm authentication is enabled on the server's management API, not just on the chat endpoint end users interact with. Model-management endpoints like /api/create are frequently left open even when a separate auth layer protects the chat path.
4. Update to the latest patched version for your platform, and re-verify the binding after updating — a warning-only patch does not change the underlying default.
5. Diff the active chat template against a known-good baseline periodically, especially after any period the host was unpatched, since a rewritten template leaves no user-visible trace.
6. Restrict outbound DNS re-resolution behavior at the network layer where you control it, and treat any local service that must remain reachable from a browser as requiring its own explicit authentication rather than relying on network position.

The general lesson: the model-serving backend is an unauthenticated internal service

The pattern underneath this specific flaw is broader than NemoClaw or Ollama. Local model-serving backends were designed as developer conveniences — start fast, bind broadly, skip auth for a single-user workstation — and that design assumption breaks the moment the same host also runs a browser that can be pointed at attacker-controlled content. Any internal service that trusts network position instead of an explicit credential is exposed the instant something on that network — a browser, a compromised neighbor process, a misconfigured proxy — can be made to reach it. DNS rebinding is one of several established techniques for defeating network-position trust from a browser context; it will not be the last one applied to a local model backend, because local inference servers are still, structurally, new enough that "who else can reach this" is not yet a default design question the way it is for a production API.

Treat every local model-serving process the same way you would treat any other unauthenticated internal service reachable from an untrusted network path: as a live target, not a background convenience. The tool-use sandboxing controls that already apply to what an agent is allowed to execute apply just as directly to what the agent's own model-serving backend is allowed to expose — and the blast radius of a poisoned chat template is every future conversation that model ever holds, not just the session where the attack occurred.

For the broader category of unauthenticated internal services agents rely on, the MCP stdio RCE vulnerability writeup covers a related but distinct exposure — a transport-layer RCE rather than a model-poisoning path — and the general sandbox-escape controls cover containment for the code-execution side of an agent's tool surface. Neither substitutes for verifying the binding and authentication state of your own local inference backend directly. The AI agent security guide is the pillar reference for the full control set — identity, sandboxing, and network egress — that this class of flaw argues for applying to local model-serving infrastructure, not only to the agent's application-layer tools.