NemoClaw Attack Chain Explained: How a Single Webpage Can Permanently Hijack Your Local LLM

You casually open what looks like a tutorial website. Seconds later, the local AI model running on your machine may have already been permanently compromised. From that moment on, every time it responds to you, it silently reads a hidden set of instructions you can never see.

This isn't science fiction. On August 25, 2025, security firm Oasis Security publicly disclosed a complete attack chain targeting NVIDIA's open-source project NeMo Agent Toolkit (dubbed NemoClaw) and the local LLM service Ollama running on top of it.

NeMo Agent Toolkit: A High-Value Target

NeMo Agent Toolkit is a reference architecture NVIDIA open-sourced in March 2025, designed to let AI Agents run securely inside sandboxes. AI Agents are a core paradigm in modern LLM applications — they don't just chat; they autonomously call tools, read and write files, and execute code. Unlike traditional chatbots, Agents operate in a closed loop of perception, decision-making, and action. This means that once an Agent is hijacked, attackers gain not just conversation content, but access to everything the Agent is authorized to operate. NeMo Agent Toolkit is the runtime framework built for exactly these scenarios, providing sandbox isolation, tool registration, and permission management — in theory, a security layer.

It ships with built-in integration for OpenClaw, the hottest open-source assistant of the moment — a project that gained 100,000 GitHub stars in just 5 days, whose author was recruited by Sam Altman into OpenAI this past February. Beyond OpenClaw, Hermes and LangChain-based Agents can also run within this framework.

NeMo Toolkit has been open source for less than six months yet has already surpassed 22,000 stars. But popularity is one thing; security is another — and this attack chain strikes precisely at the blind spot where "local deployment" is widely (and incorrectly) assumed to mean "completely safe."

Agents rely on a "brain" to do their work — and that brain is Ollama, a service that runs large language models locally on your machine. Ollama is currently the most popular tool for running local LLMs, combining model downloading, quantization, inference, and API serving into an experience that launches with a single command. Its design philosophy is "manage models like Docker" — users can pull, run, and create models the same way they work with container images. Ollama's REST API covers everything from model management (/api/pull, /api/create, /api/delete) to inference services (/api/chat, /api/generate).

It listens on port 11434, and that interface requires zero authentication. It was designed exclusively for local tooling: downloading models, creating models, chatting — all without any credentials. The reason authentication is off by default is that Ollama assumes it only runs on the local loopback address (127.0.0.1), accessible only to applications on the same machine. This is acceptable in a single-machine scenario, but the moment its listening address changes, the lack of authentication becomes a critical vulnerability.

How the Attack Works: How Can a Webpage Reach Your Local Model?

Under normal circumstances, browsers enforce the "Same-Origin Policy," which blocks external websites from accessing your localhost directly. The Same-Origin Policy is a cornerstone of the browser security model: only requests where the protocol, domain, and port are all identical are considered "same-origin"; otherwise, the browser blocks cross-origin responses. CORS (Cross-Origin Resource Sharing) is a negotiation mechanism where servers declare which external origins may access them via headers like Access-Control-Allow-Origin.

But this attack chain bypasses all of these protections through the sequential failure of three separate defenses.

Stage One: An Incorrect Listening Address Disables Security Checks

When NeMo Toolkit starts Ollama on Windows, it sets the listening address to 0.0.0.0 — meaning "listen on all network interfaces." In network programming, 0.0.0.0 is a special wildcard address that binds a service to every available network interface on the host — including the loopback interface (127.0.0.1), the LAN interface (e.g., 192.168.x.x), and any other physical or virtual adapters. In contrast, binding to 127.0.0.1 means the service only accepts connections from the local machine. In development environments, developers often use 0.0.0.0 for convenient debugging, but in everyday usage, this effectively opens the door to every device on the same network.

Changing that address triggers a cascade of failures with two immediate consequences. When Ollama is not bound to the local loopback address (127.0.0.1), its internal logic interprets this as a configuration "intentionally exposed to the outside" — causing Ollama's first line of defense, Host header validation, to be skipped entirely, and the second line, CORS checking, to also fail — because the origin and destination in the request headers appear to come from the same site.

The reason Ollama changes its validation behavior based on binding address is rooted in its code design logic. At startup, Ollama checks whether the current listening address is a local loopback address (127.0.0.1 or ::1). If it is, the code treats the environment as trusted and enforces Host header validation and CORS restrictions. The moment it detects a binding address of 0.0.0.0 or a specific LAN IP, the code interprets this as "the user intentionally wants to expose this service externally" and relaxes its restrictions — Host header validation is skipped and CORS response headers become permissive. This "infer intent from binding address" design had already surfaced as a problem in the CVE-2024-28224 fix in 2024, but the exception left in that fix was triggered again by NeMo's misconfiguration (forcing 0.0.0.0). In other words, two independent design flaws stacked together to form this complete bypass path.

Stage Two: DNS Rebinding Bypasses Browser Restrictions

The final stage is called DNS Rebinding — a clever technique that exploits the timing gap in DNS resolution to bypass the Same-Origin Policy. An attacker registers a domain they control (e.g., evil.example.com), initially pointing it to their own server's IP. After the browser loads the malicious page, the attacker changes the DNS record to 127.0.0.1 (the victim's local machine) with an extremely short TTL (typically 0 seconds). When JavaScript in the page makes subsequent requests, the browser re-resolves the domain, gets 127.0.0.1, but since the domain name hasn't changed, the browser considers it a "same-origin" request and allows it. Throughout this process, the local service on the victim's machine receives requests that look entirely legitimate — the Host header contains the attacker's domain name rather than localhost. This is precisely why Host header validation is critical — and why Stage One's decision to skip that check is so damaging.

The critical point: this entire process requires no public internet exposure of your machine. The browser making the requests is running on your own computer — the attack is launched from the inside.

DNS Rebinding continues to be effective because browsers determine "same origin" based on domain name, not the IP address the domain actually resolves to. When performing same-origin comparisons, browsers only examine the protocol, hostname, and port — they don't re-verify which IP a domain currently resolves to each time a sub-request is made. Attackers set DNS TTL to 0 or a very small value (e.g., 1 second), allowing DNS records to switch rapidly after the browser has already loaded the page. Some browsers implement "DNS Pinning" to mitigate this — caching IP resolution for the lifetime of a tab — but this is not a mandated standard, implementations vary widely, and it can be bypassed by re-resolution after a page has been open for a long time. The most reliable defense against DNS Rebinding has always been server-side: strictly validate the Host request header and reject any hostname not on an explicit whitelist, regardless of where the request originated.

The Real Damage: Permanently Hijacking the Chat Template for Prompt Injection

Once inside, what can an attacker actually do? Here's where it gets truly dangerous.

Before an LLM processes your conversation, there's a layer called the "chat template" — think of it as a formatting sheet that structures all conversation data before it's fed into the model. Chat templates are a critical component that encodes multi-turn conversations into text formats the model can understand. Different model families use different template syntax — for example, the Llama series uses [INST]...[/INST] markers, while the ChatML format uses <|im_start|>system tags. The template defines how system prompts, user messages, and assistant replies are assembled together. The model itself doesn't distinguish between these role markers and actual content — it simply processes a continuous sequence of tokens.

The attacker calls an endpoint called create and replaces this formatting sheet with a new version.

The new template silently inserts attacker-written text into every conversation, injected at the System prompt position — the place where the model receives its "rules." Because system prompts typically hold the highest priority in the model's attention mechanism (they appear first in the context window), injected instructions override any rules subsequently set by the user or Agent. The model has no eyes; the world it sees is entirely composed of what the template assembles. Change the template, and you've changed the model's entire perceived reality.

What makes this even more alarming is that the change is permanent: the chat template is stored in the model's Modelfile as part of its metadata. Regular users have no visibility into this layer from the chat interface, and there are no standardized tools to detect whether a template has been tampered with. Starting a new conversation won't help. The Agent's own system prompts can't override it. As Oasis researchers put it: "The client cannot see this template at all — there's no way to detect it."

This means your local AI is now permanently backdoored: it can see all your conversations and can use the Agent's hands to access your files and tools. As the report states: "The sandbox protects the endpoint, but once you've taken over the Agent, you've taken over all of its permissions."

Fix Status: Windows Version of Ollama Remains Unpatched

The good news first: no real-world attacks have been observed, and no CVE has been assigned.

The bad news: macOS and Linux have been patched in v0.0.35, but the Windows path remains unpatched to this day. More problematic still, the validation that was supposed to stop this attack simply doesn't execute on the WSL path. WSL (Windows Subsystem for Linux) is Microsoft's compatibility layer for running a Linux environment on Windows. WSL 2 uses a real Linux kernel running inside a lightweight virtual machine with its own network stack and IP address. When Ollama runs via the WSL path, the network configuration inside WSL has a mapping relationship with the Windows host — certain security checks that execute in the native Windows environment may simply never be triggered along WSL's network forwarding path, because the source address and network interface information may differ from expectations, causing the security logic to be bypassed.

It's worth noting that this technique is not new. Back in March 2024, Ollama patched an almost identical DNS Rebinding entry point (CVE-2024-28224), with security firm NCC Group subsequently publishing an advisory. The fix at the time was to validate the Host header, but the rules left an exception: when not bound to a local address, validation automatically disables — and 0.0.0.0 is exactly that kind of address.

This past February, OpenClaw was hijacked by a similar browser-based technique, with an official fix released within 24 hours; its skill marketplace had previously been found to contain over 1,000 malicious skill packages. Earlier this month, the same template-poisoning technique was demonstrated on another Agent called Paperclip. Old patches plus new configurations — this class of attack will almost certainly resurface.

WSL 2's network architecture is key to understanding why security checks fail on that path. WSL 2 runs a complete Linux kernel inside a Hyper-V lightweight virtual machine, with its own virtual network interface (eth0) and private IP range (typically 172.x.x.x). The Windows host and WSL 2 are interconnected via a virtual switch; network requests originating inside WSL arrive at the Windows host with a WSL virtual IP as their source address — not 127.0.0.1. When Ollama runs on this path, even if its nominal listening address is 127.0.0.1, the actual source address of requests has changed after WSL→Windows port forwarding, causing Ollama's IP-based local-origin detection logic to misfire and the security check path to be skipped. This issue requires dedicated handling at the WSL network layer or within Ollama's own logic — it cannot simply reuse the fix from the native Linux path.

Defense Guide: Four Essential Steps for Running Local Models

Here are several protective measures worth implementing immediately:

1. Upgrade NeMo and Ollama to the Latest Versions

Starting from v0.0.106, the NeMo backend will throw an error and refuse to start if it detects binding to an incorrect address. Also, never touch the environment variable that bypasses the check.

2. Bind Ollama to 127.0.0.1

Bind Ollama exclusively to 127.0.0.1. Binding to 0.0.0.0 opens every door — unless you know exactly what you're doing. This is critical: even if your machine is behind a router or firewall, DNS Rebinding attacks can be launched from the inside via a browser, bypassing all network-layer protections.

3. Add a Reverse Proxy with Authentication

The more thorough approach is to put a reverse proxy (such as Nginx or Caddy) in front of Ollama, add authentication (such as Basic Auth or token validation), and enable Host header validation at the same time. This is exactly the solution recommended in NCC Group's 2024 advisory. A reverse proxy also provides request logging and rate limiting, supplying the data needed for future security audits.

4. Regularly Audit Chat Template Integrity

Make it a habit to periodically check whether your chat templates have been modified. You can use the command ollama show <model-name> --modelfile to inspect the current model's Modelfile and verify that the TEMPLATE and SYSTEM fields match what you expect. Before this was disclosed, a media outlet reviewed the entire codebase line by line and found not a single integrity check — the application only queries the API to determine how long a context window the model supports, with zero protection over the template itself.

A Final Word: Local Deployment ≠ Security Boundary

There's no browser patch for this — it all comes down to configuration discipline. This is the one thing this incident most deserves to be remembered for:

Local deployment is not private territory, and localhost is not a security boundary.

What you run on your local machine isn't just a model file — there are templates, there are configurations. These invisible things need to be watched. As we run more and more AI Agents locally and grant them permission to access files and tools, the false sense of security that comes with the word "local" may itself become the greatest attack surface. This incident once again confirms a classic principle in security: trust boundaries must be explicitly defined and enforced, not assumed based on network topology or deployment location.