Drive-By Agent Hijacking: One Website Visit, Persistent Model Poisoning

Nemoclaw CVE-2026-65105: One Website Visit to Hijack Your AI Agent

Introduction

A vulnerability in NVIDIA NemoClaw, a tool that deploys the OpenClaw AI agent, can hand an attacker full, unauthenticated control over the local model server that powers the agent and silently plant instructions inside the model. 

A single visit to an attacker-controlled webpage is all it takes to give the attacker these capabilities. NemoClaw deploys inside NVIDIA OpenShell sandboxes with local inference via Ollama. Oasis Security discovered the vulnerability as part of ongoing research into non-human identity and AI agent risks.

NemoClaw uses Ollama as one of its supported inference backends, deploying and configuring an Ollama instance on the developer's machine as part of the NemoClaw setup, then pointing the agent at it so the model runs entirely on local hardware instead of a cloud API. The way NemoClaw configures this Ollama instance exploits a network misconfiguration that disables a critical Ollama security defense. Combined with DNS rebinding, a well-known browser-based technique for reaching local services from remote webpages, an attacker gains full access to the Ollama API. From there, the attacker can silently poison the model's chat template with instructions that survive even when the AI agent sends its own system prompt.

The result: an attacker who never touches the victim’s machine ends up steering their AI agent from that point forward.

We responsibly reported all findings to NVIDIA through their Product Security Incident Response Team (PSIRT) prior to publication.

Background

NemoClaw and OpenShell

NemoClaw is NVIDIA's tool for running the OpenClaw AI agent inside a secure OpenShell sandbox. The sandbox provides filesystem, network, and process isolation to protect the host machine from the agent's actions.

For inference, NemoClaw supports several backends. One option is local inference via Ollama, where the model runs on the developer's own hardware. This avoids sending code and prompts to external APIs, keeping everything local.

The Network Problem

OpenShell runs sandboxes inside Docker containers. For the sandbox to reach Ollama on the host machine, Ollama must listen on a network interface accessible from inside the container. Ollama's default binding, 127.0.0.1 (loopback only), is not reachable from containers. NemoClaw addresses this by starting Ollama with OLLAMA_HOST=0.0.0.0:11434, binding it to all network interfaces.

Notably, when NemoClaw is installed it prints the message Using Ollama on localhost:11434 to the user. While the API is reachable on localhost, the underlying socket is bound to 0.0.0.0 and is therefore reachable on every interface. This wording may give a user the impression that Ollama is listening only on the loopback interface, when in practice it is exposed far more broadly.

While the 0.0.0.0 binding solves the container reachability problem, it has significant security side effects.

Ollama's Security Model

Ollama is a popular open-source runtime for running large language models on local hardware; it exposes a local HTTP API on port 11434 that clients use to load models and run inference. Ollama's API on port 11434 has no authentication. Instead, it relies on two middleware layers to prevent unauthorized access from web pages:

1. CORS middleware. Checks the Origin header against an allowlist. Requests without an Origin header (typically GET requests) pass through. Requests where Origin matches Host are treated as same-origin and allowed.

2. Host header validation. Rejects requests where the Host header is not a recognized local hostname (localhost, the machine's hostname, or suffixes like .localhost, .local, .internal).

These two layers work together to block browser-based attacks. However, there is a critical exception: when Ollama is bound to a non-loopback address (such as 0.0.0.0), the Host header validation is skipped entirely. The code checks whether the bind address is loopback; if it isn't, it bypasses all Host validation.

This means that when NemoClaw binds Ollama to 0.0.0.0, only the CORS middleware remains as a defense. And as we demonstrate next, DNS rebinding bypasses it.

The Attack: DNS Rebinding to Local Ollama

How DNS Rebinding Works

DNS rebinding is a technique where an attacker sets up a domain they own and configures its DNS to resolve first to their own server's IP, then to the victim's local address (e.g. 127.0.0.1). No access to the victim's network or DNS infrastructure is needed — the attacker only controls their own domain.

The browser's same-origin policy is tied to the hostname, not the resolved IP address. When the DNS resolution changes, the browser continues to treat requests to that hostname as same-origin, even though they now reach a completely different machine.

The Attack Flow

1. The attacker sets up a domain that initially resolves to their server's public IP. The victim visits this domain on port 11434, and the browser loads the attacker's page.

2. The attacker's DNS server changes the resolution for that domain to point to 127.0.0.1 (or the victim's LAN IP).

3. JavaScript on the attacker's page makes requests to the same hostname on port 11434. The browser resolves the domain to 127.0.0.1 and sends the requests to the victim's local Ollama instance.

4. On Ollama (bound to 0.0.0.0):

• Host check: The bind address is 0.0.0.0 (not loopback) — the check is skipped entirely.
• CORS check: Origin equals "http://" + Host (both are the attacker's domain) — treated as same-origin, passes.
• Result: Full, unauthenticated API access.

What the Attacker Can Do

Once DNS rebinding succeeds, every Ollama API endpoint is accessible. The attacker's page can carry out:

Inference abuse

Destructive operations

Reconnaissance

The Payload: Model Template Poisoning

With full API access established, the most impactful action is silently poisoning the model used by the AI agent. We explored two approaches: system prompt injection and template injection.

Why System Prompt Injection Is Not Enough

The most obvious poisoning technique is injecting a hidden system field into the model via /api/create. This works when the user interacts with Ollama directly (e.g., via ollama run). However, when the OpenClaw agent queries the model, it sends its own system prompt in the messages array, which overrides the model's built-in system field. The injected system prompt is ignored during agent interactions.

Template Injection: Poisoning the Rendering Layer

Ollama's /api/create endpoint also accepts a template field. The template is a Go template that controls how the structured messages array is rendered into raw text before the model processes it. Critically, the template is applied at inference time to all messages, including any system prompt the client sends. The client has no visibility into or control over the model's template.

Below we show two templates side by side: a typical ChatML template that renders each message with its role markers (and exposes any available tools to the model), and a poisoned variant that additionally appends an attacker-controlled instruction to every system message. In practice, an attacker fetches the original template via /api/show and splices their injection into it, so all original behavior (tool rendering, special tokens, role-specific formatting) is retained and the poisoning remains undetected.

Original template, rendering messages faithfully:

Poisoned template, preserving the original tool-rendering logic and injecting attacker-controlled text into every system message:

When the OpenClaw agent sends:

The model actually receives:

The attacker's instruction is appended to whatever system prompt the client provides. The client cannot detect or prevent this, since the template is a model-level property invisible to API consumers.

Persistence and Stealth

The poisoned template:

• Persists across all future conversations with the model
• Survives client-supplied system prompts (unlike system field injection)
• Is invisible to the user: the model's name, size, metadata, and capabilities appear unchanged
• Affects all consumers of the model: direct CLI usage, API clients, and AI agents

Impact

Direct Exploitation

Even without model poisoning, the DNS rebinding attack grants the attacker full access to the Ollama API:

• GPU abuse. Run arbitrary inference on the victim's hardware, consuming GPU resources and electricity.
• Information disclosure. Enumerate models, extract system prompts and templates, exfiltrate the machine's hostname and Ollama public key.
• Destructive actions. Delete models, force sign-out, fill disk by pulling large models.

Agent Compromise via Model Poisoning

The most severe impact is the silent poisoning of the model used by the AI agent. Through template injection, the attacker can embed persistent hidden instructions that the agent will follow on every subsequent interaction.

The injected instructions could direct the agent to:

• Supply backdoor-generated code and insert vulnerabilities that pass casual review.
• Suppress security warnings by instructing the model to never flag security concerns.
• Steer recommendations toward attacker-controlled packages, URLs, or configurations.
• Exfiltrate data if the agent has outbound network access, instructing it to send conversation contents or accessed files to an external endpoint.

Beyond the Sandbox

OpenShell's sandbox provides meaningful containment — filesystem, network, and process policies limit what a compromised agent can do on the host machine. However, to effectively operate within an organization, an AI agent is typically granted access to shared resources: source control systems, CI/CD pipelines, internal APIs, cloud services, communication platforms, and tool integrations (including MCP servers).

Sandboxing protects the endpoint, but taking over the agent means controlling its access and tools. The blast radius is defined not by the sandbox boundary, but by the scope of organizational resources the agent is authorized to interact with.

LAN Exposure

The 0.0.0.0 binding also exposes Ollama to the entire local network. Any device on the same network segment can access the API directly — no DNS rebinding required. This includes other compromised machines, IoT devices, or guests on shared networks.

Demonstration

We created a proof-of-concept video that demonstrates the complete attack chain, from a single webpage visit to persistent model poisoning of the AI agent.

In the demonstration:

1. We connect to a NemoClaw sandbox and send a simple prompt to the OpenClaw agent. The agent responds normally.
2. We open a webpage in a browser that performs DNS rebinding against the local Ollama instance.
3. The page extracts the Ollama version, installed models, and the machine's hostname and public key. It then poisons the model's template with a hidden instruction.
4. We return to the sandbox and send the same prompt. The agent's response now includes the injected marker, confirming persistent, silent compromise.

Conclusion

This research demonstrates how the seemingly routine infrastructure decision of binding a service to 0.0.0.0 for container reachability can cascade into a critical vulnerability when combined with the absence of authentication and browser-based attack techniques.

The core takeaways:

1. Sandboxing the agent is necessary but not sufficient. The sandbox protects the endpoint, but the agent's authorized access — to code, tools, APIs, and organizational resources — defines the true blast radius of a compromise.
2. Binding to all interfaces is a security decision, not just a networking one. Services without authentication should never bind to 0.0.0.0 unless the implications are understood and mitigated.
3. DNS rebinding remains a potent attack against local services. Ollama's Host header validation was designed to prevent exactly this, but the 0.0.0.0 binding disables it.

As AI agents gain deeper access to development workflows and organizational infrastructure, the integrity of every component in the inference chain, from the model weights to the chat template to the network binding, becomes a security boundary worth defending.

This research was conducted in accordance with responsible disclosure practices. All findings were reported to NVIDIA through their Product Security Incident Response Team before publication.