A Malicious Webpage Can Poison Your Local Ollama Model — What Healthcare Practitioners Need to Know

AI Security

Oasis Security published a disclosure on August 25, 2026 that deserves a careful read from anyone running a local AI stack on Windows — including healthcare practitioners using local inference for privacy-sensitive workloads. The vulnerability, documented in NVIDIA's NemoClaw framework, combines an unauthenticated Ollama API binding with a DNS rebinding attack to plant persistent hidden instructions directly inside a locally running model. The instructions survive across every subsequent conversation, are invisible to API consumers, and persist through agent-supplied system prompts.

I run Ollama on Windows as part of my own local AI stack — currently serving qwen3-14b-nothink as a daily driver through AnythingLLM for RAG-based healthcare security research. My setup sits on the same platform path this disclosure is about. So this isn't abstract threat intelligence. It's a direct look at whether my own environment is in scope, what the actual risk surface is, and what local AI practitioners need to do about it.

What NemoClaw Is and Who This Affects

NemoClaw is NVIDIA's open source reference stack for running agentic workloads — specifically agents like OpenClaw inside OpenShell sandboxes, with Ollama as one of its supported local inference backends. If you're not running NemoClaw specifically, the framework-level vulnerability doesn't apply directly. But the underlying attack chain — DNS rebinding against an unauthenticated Ollama API — applies to anyone running Ollama on Windows in a configuration where the API is bound to all interfaces rather than loopback only.

NemoClaw's behavior differs by platform:

Non-WSL hosts keep Ollama on 127.0.0.1:11434 behind a token-gated reverse proxy — the safer path
Docker Desktop on WSL skips the proxy because containers reach the host's loopback via host.docker.internal
The Windows-host Ollama path sets OLLAMA_HOST=0.0.0.0:11434 so Docker Desktop containers can reach the daemon — and does not require authentication on port 11434

The Windows-host path is where the exposure lives. And it's worth noting that Ollama's own NemoClaw integration documentation also advises setting OLLAMA_HOST=0.0.0.0 when running inside WSL2 or a container — meaning practitioners who followed official guidance may have arrived at this configuration legitimately.

The Attack Chain

The attack requires three conditions: Ollama bound to 0.0.0.0:11434, no authentication on that port, and a browser on the same host visiting an attacker-controlled page. None of those conditions is unusual for a local development or practitioner stack on Windows.

With those conditions met, the chain works as follows. An attacker's domain initially resolves to their own server. The browser loads a page from that domain. The attacker's DNS then changes the resolution to 127.0.0.1 — the localhost address — while the browser continues to treat subsequent requests as same-origin. From that point, the page can make authenticated-equivalent requests to Ollama's API at 127.0.0.1:11434 directly from the browser, bypassing the Host header check that would normally block cross-origin requests.

Ollama's API has two middleware layers meant to block browser-originated requests. When the bind address is not loopback, the Host header check is skipped entirely. The CORS layer then treats the request as same-origin because the Origin and Host headers both carry the attacker's domain — now resolving to localhost. The gap closes.

This DNS rebinding technique against Ollama specifically is not new. Ollama shipped a fix in v0.1.29 in March 2024, documented as CVE-2024-28224. The NemoClaw disclosure represents a resurfacing of that same attack class in a specific deployment configuration that bypasses the prior fix.

What the Payload Actually Does

Once the API is reachable, the attack payload writes a modified Go template through Ollama's /api/create endpoint. The chat template is the mechanism that controls how the structured messages array — system prompt, user messages, assistant responses — is rendered into raw text before the model processes it. A poisoned template appends attacker-controlled text to every system message at inference time.

The poisoned template persists at the model level. Every subsequent conversation — regardless of what the user or the agent supplies as a system prompt — runs through the poisoned template first. The attacker's instructions execute before any other context.

What makes this particularly dangerous for agentic workloads is the invisibility. As Oasis Security stated: the template is a model-level property invisible to API consumers. AnythingLLM, as the API consumer sitting on top of Ollama, would have no visibility into a poisoned chat template. A RAG workspace querying a poisoned model would receive responses shaped by attacker-controlled instructions — with no indication in the API response that anything had changed. From the RAG layer's perspective, the model is just behaving differently. The cause isn't surfaced.

For a healthcare security research workflow that relies on accurate RAG retrieval and synthesis, this is a meaningful integrity concern. If the model has been poisoned to suppress certain responses, bias certain conclusions, or exfiltrate query content — none of that would be detectable from AnythingLLM's output alone.

The No-CVE Problem

One detail in the Oasis Security disclosure deserves specific attention for practitioners trying to assess their exposure: there is currently no CVE identifier, no affected version range, and no patched version. This means an operator running NemoClaw on Windows cannot check their version against a known-vulnerable range or confirm whether a patch applies to them.

The Hacker News reviewed the NemoClaw repository at commit 17f0ca3b on August 25 and found that a default introduced in v0.0.106 on August 10 causes the local Ollama proxy to refuse to start against a backend not bound to loopback. That's a meaningful mitigation — but the proxy only runs on non-WSL paths. The Windows-host Ollama path, which is where the 0.0.0.0 binding is set, doesn't start that proxy. The v0.0.106 default doesn't reach the vulnerable configuration.

Additionally, the bind probe check can be disabled by setting NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1, and it doesn't fail closed on hosts where the check cannot run. The mitigation has meaningful gaps.

The absence of a CVE also means this won't appear in standard vulnerability scanning until one is assigned. If your security program's coverage of local AI tooling depends on CVE-based scanning — which is common — this disclosure is currently invisible to it.

Checking Your Own Ollama Configuration

If you're running Ollama on Windows — with or without NemoClaw — the first question is how your Ollama daemon is bound. Check via PowerShell:

netstat -ano | findstr :11434

If the result shows 0.0.0.0:11434, your Ollama API is bound to all interfaces. If it shows 127.0.0.1:11434, you're on loopback only and not exposed to this specific attack chain from the network layer.

For my own setup: Ollama on the Desktop is running without NemoClaw — I'm using AnythingLLM as the interface layer, not OpenShell or OpenClaw agents. I'm not on the exact NemoClaw deployment path. But the underlying binding behavior and the absence of authentication on port 11434 are worth verifying regardless. If you've ever set OLLAMA_HOST=0.0.0.0 to enable Docker or WSL access, that setting persists.

To lock Ollama to loopback only, set the environment variable on the Ollama service:

OLLAMA_HOST=127.0.0.1:11434

On Windows, this is set via System Properties → Environment Variables, or via the Windows service configuration if Ollama is running as a service. Restart the Ollama service after the change and re-verify with netstat.

The Chat Template Integrity Gap

The Hacker News review of the NemoClaw repository found no chat template integrity check anywhere in the codebase. NemoClaw queries Ollama's /api/show endpoint only for a model's native context length and its declared tool-calling capability — not for template integrity.

This is the broader problem the disclosure surfaces, independent of NemoClaw: there is no standardized mechanism for an API consumer like AnythingLLM to detect that a model's chat template has been modified. The template is set at model creation time and travels with the model. Detecting poisoning requires either maintaining a known-good hash of the template and checking it at startup, or implementing out-of-band monitoring of the /api/show response over time.

Neither of those controls exists out of the box in most local AI stacks. Building them is straightforward — but requires intentional implementation.

A practical detection approach for AnythingLLM/Ollama practitioners:

Capture the /api/show response for each model at a known-good state and hash the template field
Script a periodic check that compares the current template hash against the baseline
Alert on any deviation — template changes outside of deliberate model updates should be treated as an integrity incident
Include this check in your local AI stack startup routine

This is the kind of control that doesn't exist in vendor tooling yet. It's also the kind of control that practitioners running local AI for sensitive workloads should be building themselves.

What This Means for Healthcare Local AI Deployments

The healthcare use case for local AI — privacy-sensitive data that shouldn't leave the premises, clinical research synthesis, security research workflows — is exactly the use case where model poisoning carries the highest consequence. The premise of running local inference is that the model and its outputs remain under your control. A poisoned chat template inverts that entirely: the model's inference is controlled by whoever planted the template, and the outputs are shaped accordingly without your knowledge.

For healthcare security practitioners specifically, the integrity concern extends beyond data privacy. A poisoned model in a security research workflow could suppress accurate threat analysis, bias risk assessments, or exfiltrate query content containing sensitive infrastructure details. The attack doesn't require network access to your data — it corrupts the reasoning layer that processes your data.

This disclosure is also a useful prompt to audit what local AI tooling your organization's practitioners are running. Shadow AI in healthcare isn't just cloud-based ChatGPT sessions anymore. It includes local Ollama stacks, AnythingLLM instances, LM Studio deployments, and similar tools running on endpoint workstations — often outside any formal asset management or security review process. The attack surface this disclosure describes exists on any of those endpoints where Ollama is bound to all interfaces.

The Bigger Picture

This is the third documented instance of the poisoned chat template technique in recent months — Oasis Security used a comparable approach against Paperclip earlier in August, and against local OpenClaw agents in February. The technique is maturing. The attack surface of local AI inference is expanding as more practitioners and organizations adopt local stacks.

The controls that address this class of attack are not yet standard. Authentication on the Ollama API is not enabled by default. Template integrity monitoring doesn't exist in mainstream tooling. DNS rebinding protections at the browser level have variable coverage depending on browser and OS configuration.

Until those controls become defaults, practitioners running local AI stacks carry the responsibility for implementing them. Binding to loopback is the immediate action. Template integrity monitoring is the detection layer. Both are implementable today without waiting for vendor patches.

The absence of a CVE makes this easy to defer. Don't.