AI Security - 6 min read - 27 August 2026

NVIDIA's AI agent stack bound its model server to the whole network. One webpage visit was enough to take it over.

CVE-2026-65105, disclosed by Oasis Security on 25 August, sits in NVIDIA NemoClaw - a reference stack for running OpenClaw AI agents inside OpenShell sandboxes using Ollama as the local model backend. NemoClaw starts Ollama bound to every network interface with no authentication, and a DNS rebinding attack from an ordinary webpage was enough to reach it, enumerate installed models, and plant hidden instructions that persist across every future conversation. macOS and Linux are patched in version 0.0.35; Windows and WSL are not.

NemoClaw exists to make it easy for developers to spin up a local AI agent - the open-source OpenClaw agent, running inside an OpenShell sandbox - with Ollama serving the underlying model. To make that setup work smoothly, NemoClaw launches Ollama with OLLAMA_HOST=0.0.0.0:11434, which binds the model server to every network interface on the machine rather than restricting it to localhost. Ollama does have a defence against unauthorised browser requests reaching a locally bound API - Host and Origin header validation designed to block a malicious webpage's script from talking to it directly - but that defence assumes the server is only reachable at 127.0.0.1. Bind it to 0.0.0.0 instead, and the assumption stops holding.

How a webpage visit becomes a takeover

Oasis Security's researchers used a well-known technique called DNS rebinding to get around that. A page under the attacker's control gets a victim's browser to resolve the attacker's domain to the attacker's own server first, then - after the browser has already treated the connection as same-origin - rebinds the same hostname to 127.0.0.1. The browser doesn't re-check origin trust on the switch, so requests that should have been blocked reach the exposed Ollama instance instead. From there, Oasis found they could enumerate installed models and, through Ollama's /api/create endpoint, rewrite the Go template that controls how conversation input is rendered before the model reads it - effectively injecting a hidden system prompt that rides along on every subsequent message the agent processes. No credential theft, no phishing email, no malware download. Per The Hacker News' coverage of the disclosure, one visit to the wrong page is the entire attack.

Sandboxing protected the endpoint. It didn't protect what the endpoint could reach.

OpenShell sandboxing is meant to contain what a compromised or misbehaving agent process can do to the host. What it doesn't account for is a network-exposed model server sitting outside that boundary, reachable by anything on the local network path a browser can construct. Oasis Security's head of research, Elad Luz, put the gap plainly: "Sandboxing protects the endpoint, but taking over the agent takes over its access and tools." Once the model itself is carrying injected instructions, the sandbox around the agent process is irrelevant - the attacker doesn't need to break out of it, because the poisoned model will use whatever tools and access the agent already has, from inside the boundary that was supposed to keep it safe.

The fix covers two platforms out of three

NVIDIA's PSIRT received the disclosure ahead of the 25 August public release. Version 0.0.35 resolved the underlying binding issue on macOS and Linux. Windows and WSL users got a warning added in version 0.0.34, not a fix, and remain exposed. A separate mitigation in version 0.0.106, released 10 August, added a proxy check that refuses to start against a non-loopback backend - but per Oasis's research, that check doesn't apply along WSL code paths, so the vulnerability persists there regardless of which of the two patches a Windows user has installed.

Why this isn't really a NemoClaw-only problem

Binding a local model server to every interface for the sake of a smoother setup experience is a pattern that shows up well beyond one NVIDIA tool - Ollama instances left reachable on 0.0.0.0 have been a known exposure class for a while now, usually discussed in the context of servers accidentally left open to the internet. What CVE-2026-65105 adds is the browser-based delivery mechanism: you don't need a misconfigured cloud instance, you need one employee with a local agent running and one tab open to the wrong site. As more developers run agents locally with real tool access - shells, browsers, file systems, credentials - the assumption that "it's just on my laptop" stops being much of a security boundary at all.

  • If you run NemoClaw on macOS or Linux, upgrade to 0.0.35 or later now.
  • If you run it on Windows or WSL, don't rely on the version bump alone - manually confirm Ollama is bound to loopback only until NVIDIA ships a fix that actually covers that path.
  • Audit any local AI agent tooling your developers use for OLLAMA_HOST or equivalent settings defaulting to 0.0.0.0, not just NemoClaw specifically.
  • Treat a locally-run model server as a network service that needs host firewall discipline, the same as any other local dev server - "it's just localhost" doesn't hold against DNS rebinding.
  • Periodically review agent system prompts or templates for signs of unexpected persistence, since this style of poisoning is designed to survive across sessions.

A convenience default in a developer tool turned into an unauthenticated path to hijacking whatever an AI agent has access to - and that's a design pattern worth checking for well beyond this one product. If you'd like help reviewing how your organisation's AI agent tooling is deployed and network-exposed, email sales@halfteck.com.

Explore more resources

Browse our full library of enterprise cloud, software, data and AI content.

View all resources