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.
NemoClaw runs the OpenClaw agent inside NVIDIA OpenShell sandboxes and uses Ollama for local inference, so the model runs entirely on the developer’s hardware rather than a cloud API. Oasis Security discovered the flaw while researching non-human identity and AI agent risks. They tracked it as CVE-2026-65105 and named it Nemoclaw.
The problem starts with how NemoClaw configures Ollama. To let the sandbox container reach the host’s Ollama instance, NemoClaw starts Ollama with the environment variable OLLAMA_HOST=0.0.0.0:11434, binding it to every network interface. During installation, NemoClaw prints “Using Ollama on localhost:11434.” That wording suggests the service is reachable only on the loopback interface. In practice, the underlying socket listens on 0.0.0.0 and is exposed across the entire machine.
Why the binding matters
Ollama is a widely used open-source runtime for running large language models on local hardware. It exposes an HTTP API on port 11434 with no authentication. Instead, it relies on two middleware defenses to block browser-based attacks:
1. CORS middleware, which 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, which rejects requests where the Host header is not a recognized local hostname such as localhost, the machine’s hostname, or suffixes like .localhost, .local, .internal.
There is a critical exception. When Ollama is bound to a non-loopback address such as 0.0.0.0, the code checks the bind address, finds it is not loopback, and skips Host validation entirely. Only the CORS middleware remains as a defense once NemoClaw binds Ollama to 0.0.0.0.
The attack: DNS rebinding to the local Ollama
DNS rebinding is a browser-based technique in which an attacker controls a domain that first resolves to the attacker’s server, then changes to resolve to a local address such as 127.0.0.1. The browser’s same-origin policy is tied to the hostname, not the IP address, so when DNS resolution flips, the browser continues to treat requests to that hostname as same-origin even though they now reach a different machine. The attacker never needs access to the victim’s network or DNS infrastructure; they only need to control their own domain.
The attack flow:
1. The attacker sets up a domain that initially resolves to the attacker’s public server. The victim visits the domain on port 11434 and loads the attacker’s page.
2. The attacker’s DNS server changes the domain’s resolution to 127.0.0.1 or the victim’s LAN IP.
3. JavaScript on the attacker’s page sends requests to the same hostname on port 11434. The browser now resolves the domain to 127.0.0.1 and delivers the requests to the local Ollama instance.
4. On Ollama bound to 0.0.0.0:
– Host check: skipped, because 0.0.0.0 is not loopback.
– CORS check: Origin equals “http://” plus Host, both the attacker’s domain, so the request is treated as same-origin and passes.
– Result: full, unauthenticated API access.
What the attacker can do
Once DNS rebinding succeeds, every Ollama API endpoint is reachable from the attacker’s page.
Inference abuse:
– POST /api/generate: run arbitrary prompts on the victim’s GPU
– POST /api/chat: chat completions on the victim’s hardware
– POST /v1/chat/completions: OpenAI-compatible inference
Destructive operations:
– POST /api/create: overwrite models used for poisoning and model configurations
– POST /api/pull: download arbitrary models and fill disk
– POST /api/push: push models to ollama.com under the victim’s account
– DELETE /api/delete: delete the victim’s models
– POST /api/signout: force sign-out from ollama.com
Reconnaissance:
– GET /api/tags: list all installed model names, sizes, families, and quantization levels
– GET /api/version: return the exact Ollama version
– POST /api/show: expose full model details including system prompts, templates, and licenses
– POST /api/me: reveal the machine’s hostname and public key, or username if signed in
The payload: model template poisoning
With full API access, the most impactful move is silently poisoning the model the AI agent uses. Oasis Security tested two approaches: system prompt injection and template injection.
System prompt injection falls short. The obvious approach is to inject a hidden system field into the model via /api/create. This works when a user interacts with Ollama directly, such as through ollama run. When the OpenClaw agent queries the model, however, 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 targets 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.
A typical ChatML template renders each message with its role markers and exposes any available tools to the model. A poisoned variant preserves that original logic and appends an attacker-controlled instruction to every system message. In practice, the attacker fetches the original template via /api/show, splices the injection into it, and retains all original behavior: tool rendering, special tokens, and role-specific formatting remain intact, so the poisoning goes unnoticed.
When the OpenClaw agent sends its own system prompt, the model receives the prompt with the attacker’s instruction appended. The client cannot detect or prevent this, because 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 in a way system field injection does not, is invisible to the user (the model’s name, size, metadata, and capabilities appear unchanged), and affects all consumers of the model, including direct CLI usage, API clients, and AI agents.
Direct exploitation impact
Even without model poisoning, the DNS rebinding attack grants 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, and exfiltrate the machine’s hostname and Ollama public key.
– Destructive actions: delete models, force sign-out, and fill disk by pulling large models.
Agent compromise via model poisoning
The most severe impact is silent poisoning of the model used by the AI agent. Through template injection, the attacker embeds persistent hidden instructions 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. To operate effectively inside an organization, however, an AI agent is typically granted access to shared resources, including source control systems, CI/CD pipelines, internal APIs, cloud services, communication platforms, and tool integrations such as 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, without DNS rebinding. That includes other compromised machines, IoT devices, or guests on shared networks.
Demonstration
Oasis Security produced a proof-of-concept video showing the complete attack chain, from a single webpage visit to persistent model poisoning of the AI agent:
1. They connected to a NemoClaw sandbox and sent a simple prompt to the OpenClaw agent. The agent responded normally.
2. They opened a webpage in a browser that performed DNS rebinding against the local Ollama instance.
3. The page extracted the Ollama version, installed models, and the machine’s hostname and public key, then poisoned the model’s template with a hidden instruction.
4. They returned to the sandbox and sent the same prompt. The agent’s response now included the injected marker, confirming persistent, silent compromise.
Disclosure
Oasis Security reported all findings to NVIDIA through NVIDIA’s Product Security Incident Response Team (PSIRT) prior to publication.
What this case shows
– 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.
– 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.
– 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.