Security researchers have disclosed a weakness in NVIDIA NemoClaw that could allow an attacker-controlled webpage to gain unauthenticated access to a locally running Ollama AI server and secretly alter how its models behave.
The vulnerability was disclosed by Oasis Security and affects certain NemoClaw configurations that use Ollama for local AI inference.
Rather than exploiting the language model itself, the attack targets the infrastructure surrounding it. By combining an exposed Ollama API with a technique known as DNS rebinding, a malicious website can potentially communicate with an AI service running on the victim's own computer.
Researchers demonstrated that this access can be used to modify a model's chat template, inserting hidden attacker-controlled instructions that can influence future AI conversations.
This is particularly concerning for AI agents because the malicious instructions can remain outside the visible conversation and continue affecting the model across later sessions.
What Is NVIDIA NemoClaw?
NemoClaw is NVIDIA's open-source reference stack for running AI agents in isolated environments using NVIDIA OpenShell.
One of its supported options is Ollama, a popular platform that allows large language models to run locally instead of relying entirely on cloud-based AI services. NVIDIA's documentation describes how NemoClaw can route inference requests to an Ollama server running on the same machine.
Running AI locally can provide privacy, performance and control advantages.
However, the local inference service itself becomes an important security boundary.
The NemoClaw research demonstrates what can happen when that boundary is accessible more broadly than expected.
How the Attack Works
The issue stems from configurations in which Ollama is bound to: 0.0.0.0:11434
Binding a service to 0.0.0.0 means it listens on all available network interfaces, rather than only the local loopback interface.
Ollama's API on port 11434 does not provide conventional authentication by default.
Researchers found that this configuration could therefore expose the local model server in a way that allowed browser-originated requests to reach it.
The attack then uses DNS rebinding.
In simplified terms:
- A victim visits a webpage controlled by an attacker.
- The attacker's domain initially resolves to the attacker's own web server.
- The attacker changes the DNS response so the same domain resolves to a local address on the victim's computer.
- The browser can then be tricked into sending requests toward the locally running Ollama service.
- The attacker can interact with the Ollama API without needing a username or password.
The technique exploits the gap between how the browser identifies the website's origin and where the domain ultimately resolves on the network.
According to reporting on the Oasis research, the complete attack chain was demonstrated using a vulnerable NemoClaw configuration.
From Browser Access to AI Model Poisoning
Gaining access to the local inference API is already serious, but the researchers demonstrated a more persistent attack.
Using Ollama's model-management functionality, an attacker can modify the model's chat template.
A chat template determines how elements such as:
- system instructions
- user prompts
- assistant messages
are formatted before they are passed to the language model.
Researchers showed that an attacker could modify this template to silently append their own instructions to system messages.
Those instructions can then affect subsequent conversations processed by the model.
Importantly, this is not poisoning of the underlying neural-network weights.
The attacker instead poisons the model's inference configuration — specifically the template used to construct prompts.
That distinction matters because the model itself may still appear legitimate while its behaviour has been altered by a hidden layer of instructions.
Why Persistent Instructions Are Dangerous
Ordinary prompt injection normally arrives as part of a conversation, document or webpage being processed by an AI system.
This attack is different.
The malicious instruction can become part of the model's persistent configuration.
According to the researchers, the poisoned chat template can apply attacker-controlled instructions to future conversations even when the AI agent supplies a new legitimate system prompt.
Applications communicating with Ollama may also have no obvious indication that the template has changed.
This creates an AI integrity problem.
A compromised agent might continue looking operational while its decisions or responses are being influenced by instructions the user cannot see.
What Could an Attacker Do?
Once an attacker gains access to the exposed Ollama API, Oasis researchers reported capabilities including:
- enumerating locally installed models
- initiating inference workloads using the victim's computing resources
- inspecting model information and templates
- modifying or deleting models
- changing model configuration
- inserting persistent instructions into chat templates
The real-world impact of model poisoning would depend heavily on what permissions the affected AI agent has.
An isolated chatbot with no external capabilities presents a different risk from an autonomous agent that can access files, development tools, APIs, credentials or other business systems.
That is one of the broader lessons of the disclosure: compromising the inference layer can indirectly compromise the behaviour of the agent using it.
The Sandbox Does Not Solve Everything
NemoClaw uses sandboxing as an important security mechanism around AI agents.
But sandboxing and inference-server security address different problems.
If an attacker gains control over the model generating instructions for the agent, the attacker may be able to influence actions that the sandbox legitimately permits.
As Oasis Security summarized, protecting the environment around an agent does not remove the need to protect the model infrastructure that drives its decisions.
This principle applies well beyond NemoClaw.
Organizations deploying local AI increasingly need to consider model servers, inference APIs and agent orchestration layers as part of their normal cybersecurity perimeter.
Which NemoClaw Versions Are Affected?
The version situation requires some caution.
Initial reporting did not identify a CVE or provide a single authoritative affected-version range for every supported NemoClaw platform.
Oasis Security's head of research told The Hacker News that NemoClaw v0.0.35 addressed the reported issue for macOS and Linux, while the Windows and WSL deployment path did not receive the same complete remediation at that stage.
Current NVIDIA documentation shows that on supported non-WSL configurations, NemoClaw keeps Ollama on: 127.0.0.1:11434
and places a token-authenticated reverse proxy in front of it for sandbox connectivity. NVIDIA explicitly states that this path does not expose Ollama without authentication.
NVIDIA's security documentation also recognizes the risk of a non-loopback Ollama backend because direct access to such a backend could bypass the authenticated proxy.
Administrators should therefore evaluate their actual Ollama binding and topology, rather than relying solely on a NemoClaw version number.
No Evidence of Active Exploitation
As of the public disclosure on August 25, 2026, there was no reported evidence that attackers were exploiting the NemoClaw weakness in real-world attacks.
The issue should therefore be treated as a demonstrated security weakness rather than an active exploitation campaign unless new evidence emerges.
That distinction is important when assessing urgency and communicating risk.
What Organizations Should Do
Organizations running NemoClaw with local Ollama inference should review their configuration now.
✅ Keep Ollama on Loopback
Where possible, Ollama should listen only on: 127.0.0.1
rather than 0.0.0.0.
A model API intended only for local use should not be unnecessarily accessible from other network interfaces.
✅ Use Authenticated Proxies
Where NemoClaw supports its authenticated Ollama proxy, organizations should keep that protection enabled and avoid configurations that allow clients to bypass it.
NVIDIA's current implementation uses a token-gated proxy while keeping the Ollama backend bound to loopback on supported non-WSL deployments.
✅ Do Not Expose Port 11434
Administrators should ensure TCP port 11434 is not unnecessarily exposed to:
- the local network
- public Wi-Fi
- corporate user networks
- the internet
Network-level controls should reinforce the local binding.
✅ Review Model Integrity
Organizations using local AI models should consider monitoring more than model files and hashes.
Configuration elements such as chat templates can materially change model behaviour without modifying the underlying model weights.
Unexpected changes to templates, system prompts or model definitions should therefore be treated as potentially security-relevant events.
✅ Update NemoClaw
Administrators should run a current NemoClaw release and review NVIDIA's latest deployment guidance.
NVIDIA has continued strengthening local inference handling, including checks designed to prevent Ollama backends from listening beyond loopback in configurations protected by its local proxy.
A Broader Warning for Local AI
The NemoClaw disclosure highlights an emerging cybersecurity challenge.
Organizations often consider a locally hosted AI model safer because data does not need to leave the device or corporate environment.
But local does not automatically mean secure.
A local model server is still a network service.
It requires the same fundamental protections as other sensitive infrastructure:
- authentication
- network isolation
- secure defaults
- access control
- configuration integrity
- monitoring
- regular updates
The growing use of autonomous AI agents makes these controls even more important.
An AI model is no longer always a system that simply generates text. It may influence software development, access corporate information, communicate with external systems or initiate automated actions.
Protecting the integrity of the inference layer therefore becomes part of protecting everything the agent is allowed to do.
Final Thoughts
The NVIDIA NemoClaw research demonstrates how a traditional web technique such as DNS rebinding can take on new significance when applied to modern AI infrastructure.
A malicious webpage does not need to compromise the model mathematically. If it can reach an unauthenticated local inference service, changing the configuration surrounding the model may be enough to influence its future behaviour.
For businesses experimenting with local AI agents, this should be an important reminder to examine the infrastructure underneath the model — not only the model itself.
Local AI infrastructure must be treated like any other privileged service. Keep inference APIs isolated, authenticate access, protect model configuration and never assume that “localhost AI” is automatically safe.
