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.
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.
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 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:
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.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.
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.
127.0.0.1 (or the victim's LAN IP).127.0.0.1 and sends the requests to the victim's local Ollama instance.0.0.0.0 (not loopback) — the check is skipped entirely.Origin equals "http://" + Host (both are the attacker's domain) — treated as same-origin, passes.Once DNS rebinding succeeds, every Ollama API endpoint is accessible. The attacker's page can carry out:
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.
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.
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.
The poisoned template:
Even without model poisoning, the DNS rebinding attack grants the attacker full access to the Ollama API:
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:
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.
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.
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:
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:
0.0.0.0 unless the implications are understood and mitigated.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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。