TL;DR: A flaw in NVIDIA’s NemoClaw (CVE-2026-65105, CVSS 8.1) started Ollama bound to 0.0.0.0:11434 with no authentication, so any webpage you visit could DNS-rebind to your local API, read your models and hostname, and rewrite the model’s chat template to inject hidden instructions that survive reboots. NemoClaw v0.0.35 fixes it on macOS and Linux — Windows/WSL is still unpatched. Even if you never touched NemoClaw, the underlying lesson applies to every self-hosted Ollama box.

	You run NemoClaw	You run plain Ollama	You browse on a separate machine
At risk?	Yes, if Ollama binds 0.0.0.0	Only if you set OLLAMA_HOST=0.0.0.0	No — the attack needs a browser on the same host
Fix	Update to v0.0.35 (macOS/Linux)	Bind to 127.0.0.1, firewall port 11434	Already isolated; verify the bind anyway
Time to fix	2 minutes	5 minutes	1 minute to confirm

Honest take: this bug is real but narrow — it needs you to visit a hostile page on the same machine that serves your models. Fix it in five minutes anyway: bind Ollama to loopback, block 11434 at the firewall, and don’t run a browser on your inference box. Those three habits close this hole and every future one shaped like it.

On August 25, 2026, researchers at Oasis Security (now part of Cyera) disclosed CVE-2026-65105, a vulnerability in NVIDIA’s NemoClaw that turns an ordinary browser tab into a path straight to your local AI model. It carries a CVSS score of 8.1 (High) — vector CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H — and the ugly part is what it lets an attacker do: not just read what’s on your machine, but quietly edit the model’s behavior so every future answer carries instructions you never wrote.

If you run local models, this is worth ten minutes of your attention, and not only because of NemoClaw. The root cause is a mistake anyone can make with Ollama, and the fix is the same set of habits that should have been in place all along.

What NemoClaw is, and why the bug hurts more here

There’s a bitter irony in this one. NemoClaw is NVIDIA’s open-source security stack for OpenClaw — it wraps the OpenClaw agent in the OpenShell runtime to give you kernel-level sandboxing (Landlock, seccomp, network namespaces), network policy controls, and audit trails. The whole pitch is “run AI agents you can actually trust.” It’s Apache 2.0, has 9k+ GitHub stars, and supports local inference through Ollama and NVIDIA Nemotron so your agent’s model never has to leave the box.

So the tool whose entire job is to lock an agent down is the tool that opened the door. NemoClaw’s deployment wrapper started Ollama with OLLAMA_HOST=0.0.0.0:11434 — a reasonable-looking choice, because the sandboxed agent runs in a container and needs to reach the model server on the host. Binding to 0.0.0.0 makes Ollama reachable from that container. It also makes Ollama reachable from every network interface on the machine, and Ollama ships with no authentication of any kind.

That single line is the vulnerability. Everything else is the browser doing exactly what browsers do.

The attack, step by step

Ollama does have one defense against a random webpage talking to it: when it’s bound to loopback, it validates the Host header and rejects cross-origin requests. The problem, as Oasis researchers Elad Luz and Ofek Itach found, is that Ollama skips Host-header validation when it’s bound to a non-loopback address — including 0.0.0.0. NemoClaw’s default flipped exactly that switch.

Here’s the chain, which is a textbook DNS rebinding attack:

1. You visit a malicious page. The attacker owns a domain — say evil.example — that initially resolves to their own server on port 11434. Nothing local has happened yet.
2. The domain rebinds to localhost. After the page loads, the attacker’s DNS re-resolves evil.example to 127.0.0.1. The browser’s same-origin policy keys on the hostname, not the IP behind it, so from the browser’s point of view the page is still talking to evil.example and same-origin. The requests now land on your Ollama instance.
3. Both Origin and Host headers say evil.example. Because Ollama is bound to 0.0.0.0, it never checks them — and even if it did, they match the attacker’s domain, so its CORS middleware treats the calls as same-origin.
4. Reconnaissance. The page calls Ollama’s HTTP API and lifts your Ollama version, your installed model list, your machine’s hostname, and your machine’s Ollama public key. It can also delete models outright.
5. Persistent poisoning. The page calls /api/show to fetch a model’s existing chat template, injects hidden text into the Go text/template that renders every message before inference, and re-uploads the tampered version through /api/create.

Step 5 is the one that should make you sit up. A stolen model list is annoying; a poisoned template is structural. The chat template sits between your messages and the inference engine, so attacker text gets appended to the system-message render path of every conversation from then on — invisible to anything reading the API responses, and surviving reboots because it’s written to the model on disk. Cyera’s proof-of-concept did exactly this: connected to a NemoClaw sandbox, poisoned the template from a browser, and watched the agent’s next answer come back carrying the injected marker. Silent, persistent compromise from one page visit.

No exploitation in the wild had been reported as of the August 25 disclosure. This was responsible disclosure — Oasis reported it to NVIDIA’s PSIRT before going public — not an incident report. But the window between “publicly documented” and “someone weaponizes it” is short, so treat it as live.

Am I affected?

Walk these three questions:

• Do you run NemoClaw? If yes, and it started Ollama on 0.0.0.0, you were exposed. Update immediately (next section).
• Do you run plain Ollama with OLLAMA_HOST=0.0.0.0? Then you have the same underlying exposure NemoClaw created — any browser on that host can reach your unauthenticated API. People set this constantly to reach Ollama from another device on the LAN, from Open WebUI in Docker, or from a phone. It’s the single most common Ollama connection fix on the internet, and it quietly removes the Host-header defense.
• Do you browse the web on the same machine that serves your models? The attack needs a browser on the inference host. If your models live on a headless box and you browse from a laptop, this specific attack can’t reach you — though you should still bind to loopback on principle.

If you set OLLAMA_HOST=0.0.0.0 and also browse on that machine, you are the exact target profile. That combination is depressingly normal on a single-PC home lab.

Fix 1: NemoClaw users, update now

Update NemoClaw to v0.0.35 or later. The fix is architectural, not a patch to the old binding: Ollama now runs on 127.0.0.1:11434 (loopback only), and a token-gated reverse proxy handles any traffic that legitimately needs external reach, on a separate port (0.0.0.0:11435). A browser doing DNS rebinding lands on the proxy, which demands a token it doesn’t have, instead of hitting the Ollama API directly.

One critical caveat the headlines gloss over: v0.0.35 patches macOS and Linux only. Windows and WSL remain unfixed as of this writing. If you run NemoClaw on Windows or under WSL, updating is not enough — you must apply the manual Ollama hardening below and treat the box as exposed until NVIDIA ships a Windows patch. Check the NemoClaw releases page before assuming you’re covered.

Fix 2: the hardening checklist for every Ollama box

This is the part that outlives NemoClaw. Whether or not you touch that tool, these five steps close the class of bug entirely. Tested against Ollama v0.32.x (v0.32.15 was current in late August 2026).

1. Bind to loopback (the one that matters most)

Ollama’s own FAQ is blunt: it binds 127.0.0.1:11434 by default because it has no built-in authentication or authorization. If you never changed that, you’re already safe from this attack. If you set OLLAMA_HOST=0.0.0.0, undo it unless you have a hard requirement — and if you do, put a real auth layer in front (next steps).

Linux (systemd): shell exports do not apply to a systemd service, which is the number-one reason people think they’ve changed the bind and haven’t. Edit the unit:

sudo systemctl edit ollama

Remove or fix any Environment="OLLAMA_HOST=0.0.0.0:11434" line in the [Service] section so it reads 127.0.0.1:11434 (or delete it to use the default). Then:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Also grep your shell configs — ~/.bashrc, ~/.zshrc, ~/.profile — for a stray OLLAMA_HOST export that a manually launched ollama serve would pick up.

macOS: if you set it with launchctl setenv OLLAMA_HOST 0.0.0.0, clear it with launchctl unsetenv OLLAMA_HOST and restart the app. A shell export only affects ollama serve started from that shell.

Windows: remove the OLLAMA_HOST user environment variable (search “Edit environment variables for your account”), quit Ollama from the tray, and relaunch.

2. Block port 11434 at the firewall

Defense in depth, in case something re-sets the bind:

# Linux, ufw
sudo ufw allow from 127.0.0.1 to any port 11434
sudo ufw deny 11434

Confirm your router does not forward port 11434 to this machine. If you’ve ever port-forwarded for remote access, remove that rule — an unauthenticated Ollama exposed to the open internet is far worse than the DNS-rebinding case.

3. Reach it remotely the safe way

If the reason you set 0.0.0.0 was to use your rig from another device, don’t expose the raw port — put it on a private overlay network instead. A Tailscale mesh gives you access from anywhere without opening a single inbound port, so Ollama can stay bound to loopback (or to the Tailscale interface only) while your laptop and phone still reach it over the encrypted tailnet. That’s the pattern to copy.

4. Isolate your browsing

The attack is inert without a browser on the inference host. The cleanest architecture is physical: serve models on a dedicated headless box and browse from a different machine. This is why a lot of home labbers run a quiet, always-on inference server — a used RTX 3090 tower (24GB, ~$972 sold-average on eBay through late August 2026 per BestValueGPU) makes a capable one — and keep the daily-driver laptop for web and email. If one machine has to do both, run your web browsing in a separate browser profile or a throwaway VM. Prefer zero local footprint entirely? Renting a cloud GPU on RunPod keeps inference off any machine you browse on.

5. Verify, don’t assume

Confirm what Ollama is actually bound to:

# Linux / macOS
netstat -tlnp | grep 11434
# or, more portably:
ss -tlnp | grep 11434

You want to see 127.0.0.1:11434, not 0.0.0.0:11434 or :::11434. On Windows, use netstat -ano | findstr 11434. While you’re in there, list your models and look for anything you didn’t pull:

ollama list

If a model looks tampered with, remove and re-pull it — the poisoning lives in the on-disk template, so a fresh pull from a trusted source clears it.

The honest scope — don’t panic, don’t ignore

Two things are true at once. The bug is genuinely serious: template poisoning is stealthy, persistent, and hits every future conversation, and NVIDIA’s own security tool shipped the misconfiguration. But the attack surface is narrow: it requires an attacker to serve you a malicious page and you to open it on the machine running Ollama on 0.0.0.0. A headless server you never browse from is not reachable this way, and default-install Ollama (loopback-bound) was never vulnerable to begin with.

The reason to act isn’t this one CVE — it’s that the fix is the correct baseline regardless. An unauthenticated local API on all interfaces is a standing liability; DNS rebinding is just today’s way of reaching it. Bind to loopback, firewall the port, keep a browser off the box, and reach it over a private overlay. Do that once and CVE-2026-65105 is a non-event, along with whatever the next one looks like.

If you’re thinking harder about what your local stack exposes, our local AI privacy audit walks through what data actually stays on your machine, and the air-gapped workstation guide covers the maximal-isolation end of the spectrum. For the FOSS tooling angle on patching NemoClaw itself, aifoss.dev has a companion write-up, and if you drive Ollama as a coding backend through Cline or Cursor, aicoderscope.com covers the BYOK setup that keeps that traffic local too.

FAQ

Do I need to worry if I never installed NemoClaw? Only if you run Ollama bound to 0.0.0.0 and browse on that same machine. Default Ollama binds to 127.0.0.1 and isn’t reachable by this attack. Check with ss -tlnp | grep 11434.

I updated NemoClaw to v0.0.35 — am I done? On macOS or Linux, yes for this CVE. On Windows or WSL, no — those platforms are still unpatched as of late August 2026, so apply the manual loopback bind and firewall rule and watch the releases page.

How would I know if my model was already poisoned? The tampering lives in the chat template, so it won’t show in normal API responses. If you ran an exposed setup and browsed the web on it, remove and re-pull your models from a trusted source. ollama list shows what’s installed; anything unexpected is a red flag.

Can’t I just add authentication to Ollama instead? Ollama has no built-in auth — that’s the design. The supported way to add it is a reverse proxy (nginx, Caddy, or NemoClaw’s own token-gated proxy) in front, or an overlay network like Tailscale so only trusted devices can reach it. Binding to loopback is still the first move.

Why does binding to 0.0.0.0 disable the Host-header check? Ollama treats a loopback bind as “local only” and validates Host/Origin to block cross-origin browser calls. Once you bind to a routable interface, it assumes you meant to expose it and drops that check — which is exactly the assumption DNS rebinding abuses. It’s not a bug in that logic so much as a reason never to bind wide without auth in front.

Sources

• A Malicious Webpage Could Poison Your Local AI Model Behind NVIDIA NemoClaw — The Hacker News
• Drive-By Agent Hijacking: One Website Visit, Persistent Model Poisoning — Cyera / Oasis Security
• Nvidia NemoClaw flaw let attackers poison the model behind a developer’s AI agent — SiliconANGLE
• NemoClaw’s AI can be poisoned through a browser tab — CSO Online
• Finding Nemo(Claw): Issue Allows for LLM Poisoning in OpenClaw — Dark Reading
• CVE-2026-65105 record — THREATINT
• NemoClaw — NVIDIA (GitHub)
• Ollama FAQ — binding, network exposure, and authentication
• RTX 3090 used price tracker, August 2026 — BestValueGPU

Last updated August 27, 2026. Vulnerability status and patch coverage change quickly; verify the current NemoClaw release and your own bind configuration before relying on any single detail here.