TL;DR: CVE-2026-65105 (CVSS 8.1, disclosed August 2026 by Oasis Security) is a flaw in NVIDIA NemoClaw, the Apache 2.0 agent-sandboxing stack: it launched its bundled Ollama bound to 0.0.0.0:11434 instead of loopback, so any website you visit could use DNS rebinding to call Ollama’s unauthenticated API — enumerate your models and rewrite a model’s chat template so injected instructions persist across every later conversation. Update NemoClaw, and check your own Ollama bind address even if you have never installed NemoClaw.

	Patched NemoClaw / default Ollama	Unpatched NemoClaw	Manual OLLAMA_HOST=0.0.0.0
Ollama bind	127.0.0.1:11434	0.0.0.0:11434	0.0.0.0:11434
Reachable from	Same machine only	Browser JS via DNS rebinding, plus the whole LAN	Browser JS via DNS rebinding, plus the whole LAN
Exposure	None known	Model enumeration, persistent template poisoning	Same as unpatched NemoClaw
What to do	Nothing — verify with ss -tlnp	Update now	Bind loopback; tunnel for remote access

Honest take: If you run plain Ollama with default settings on one machine, you were never vulnerable to this specific bug — but the same drive-by attack works on anyone who set 0.0.0.0 for convenience, so spend the five minutes on the audit section below anyway.

What is CVE-2026-65105?

CVE-2026-65105 is a high-severity vulnerability (NVIDIA rates it CVSS 3.1 base 8.1, classified CWE-306, missing authentication) in NVIDIA NemoClaw, disclosed in late August 2026 by Oasis Security researchers Elad Luz and Ofek Itach.

NemoClaw is NVIDIA’s open-source reference stack for running AI coding agents — OpenClaw by default, with Hermes and LangChain Deep Agents also supported — inside OpenShell sandboxes, with managed local inference. The license is Apache 2.0, confirmed from the LICENSE file at github.com/NVIDIA/NemoClaw, and the repository sits at roughly 22.8k stars as of October 19, 2026. The project’s pitch is ironic in hindsight: it exists to run agents more safely, but its managed-inference piece started the bundled Ollama server with OLLAMA_HOST=0.0.0.0:11434 — listening on every network interface instead of only loopback.

Ollama’s HTTP API has no authentication of any kind. Whoever can open a TCP connection to port 11434 can list models, pull models, delete models, and create new ones. Binding it to anything other than 127.0.0.1 hands that API to the local network — and, through the browser trick below, to any webpage you happen to load.

How does the DNS rebinding attack against Ollama work?

DNS rebinding lets a malicious webpage talk to services on your private network by changing what its own domain name resolves to after the page has loaded. The sequence Oasis Security demonstrated:

1. You visit attacker-site.com. Its DNS record, served with a very short TTL, initially points at the attacker’s real server, which returns a page with JavaScript.
2. The attacker flips the DNS record so attacker-site.com now resolves to 127.0.0.1 (or your machine’s LAN address).
3. The page’s JavaScript keeps making requests to attacker-site.com:11434. The browser re-resolves the name and now delivers those requests to your local Ollama — and because the hostname matches the page’s own origin, the browser’s same-origin policy does not object.
4. The script enumerates installed models via the API, then uses the model-create endpoint to rewrite an existing model’s chat template, embedding hidden instructions.

Step 4 is what made this more than an information leak. A poisoned chat template is stored on disk as part of the model definition, so the injected instructions survive reboots and apply to every future conversation with that model — whether you talk to it through Open WebUI, a coding agent, or ollama run. Oasis called it persistent model poisoning; you can think of it as a drive-by system prompt implant.

Ollama itself patched a DNS rebinding hole once already — CVE-2024-28224, fixed in Ollama v0.1.29 back in March 2024 — by validating incoming Host headers on its default loopback binding. NemoClaw’s 0.0.0.0 configuration reintroduced the exposure around that protection, which is why this CVE belongs to NemoClaw, not Ollama.

Which NemoClaw versions are affected, and what is the fix?

Update NemoClaw to the latest release and then verify the Ollama bind address yourself — the public record on exact version numbers is inconsistent. eSecurityPlanet reported NVIDIA patched the flaw on August 25, 2026 and listed NemoClaw for Linux versions 0 through 0.0.25 as affected; other coverage names v0.0.35 as the fixed release for macOS and Linux and reported that Windows/WSL deployments had received only a warning, not a structural fix, at disclosure time. The project’s GitHub releases page does not surface a tagged advisory entry we could confirm (checked October 19, 2026), so treat “update, then verify” as the procedure rather than trusting any single version number:

# After updating, confirm the bundled Ollama is loopback-only:
ss -tlnp | grep 11434
# Good:  127.0.0.1:11434
# Bad:   0.0.0.0:11434  or  *:11434  or  [::]:11434

If you run NemoClaw on WSL, assume you are still in the risk group until NVIDIA’s advisory says otherwise for your platform, and apply the firewall and binding steps below as compensating controls.

Am I affected if I never installed NemoClaw?

Yes, if — and only if — your Ollama listens on a non-loopback address. Ollama’s own default is 127.0.0.1:11434, which this attack cannot reach. But OLLAMA_HOST=0.0.0.0 is the single most common tweak self-hosters make, because it is the quickest way to let Open WebUI in a Docker container, a laptop on the couch, or a coding agent on another machine reach the API. Every one of those setups has the same exposure NemoClaw shipped: any browser on any machine that can route to port 11434 is a potential relay for the attack above.

The risk profile is specifically the single-user home setup where a browser and Ollama share a machine or a flat home LAN. This is a different failure mode from the thousands of Ollama instances exposed directly to the public internet — we counted that mess in our exposed-instances audit — but the root cause is identical: an unauthenticated API bound wider than it needs to be.

How do I audit my Ollama binding in two minutes?

Check what the port is bound to, confirm it answers locally, and confirm it does not answer from outside:

# 1. What address is Ollama listening on?
ss -tlnp | grep 11434            # netstat -tlnp works too

# 2. Where is OLLAMA_HOST being set?
systemctl cat ollama | grep -i OLLAMA_HOST     # systemd installs
grep -ri "OLLAMA_HOST" ~/.bashrc ~/.zshrc /etc/environment 2>/dev/null
docker inspect ollama | grep -i OLLAMA_HOST    # Docker installs

# 3. Local API answers:
curl -s http://127.0.0.1:11434/api/version

# 4. From ANOTHER machine on your LAN — this should time out or refuse:
curl --connect-timeout 3 http://<your-host-ip>:11434/api/tags

While you are in there, check for tampering: ollama list for models you did not pull, and ollama show <model> --modelfile on the models you use daily — read the TEMPLATE and SYSTEM blocks and make sure nothing has been appended that you did not put there. A poisoned template is plainly visible in that output; it just is not something anyone thinks to look at.

Hardening checklist for self-hosted Ollama

Each item stands alone; the first two cover most people.

• Bind loopback. Remove any OLLAMA_HOST=0.0.0.0 from systemd units, shell profiles, .env files, and Docker Compose. Ollama’s default needs no env var at all.
• If containers need access, scope it. For Open WebUI on the same host, publish Ollama to the Docker bridge only (OLLAMA_HOST=172.17.0.1:11434 plus a firewall rule, or put both services on one user-defined Docker network) instead of 0.0.0.0.
• Firewall the port anyway. sudo ufw deny in on <wan-facing-interface> to any port 11434 — defense in depth costs one line.
• Remote access via overlay, not exposure. Tailscale (free tier covers 3 users/100 devices as of October 2026) or an SSH tunnel (ssh -L 11434:127.0.0.1:11434 user@host) gives other machines the API without giving it to the LAN or any browser.
• Multi-user LAN serving belongs behind a reverse proxy that adds authentication — the pattern in our self-hosted AI privacy stack guide.
• Agent stacks deserve extra skepticism. If a coding agent uses local Ollama as a BYOK backend (the setups we compared in Kilo Code vs OpenCode vs Cline), the model’s output steers tool calls — a poisoned template upstream of an agent with shell access is how a browser tab becomes code execution. The containment patterns from the Kimi K3 incident write-up apply here too.

When is binding 0.0.0.0 actually fine?

Almost never on a machine that also runs a browser, and never on a laptop that leaves the house. The defensible cases: a headless inference box on an isolated VLAN with firewall rules allowing only known client IPs, or a cloud GPU instance whose security group restricts port 11434 to your own addresses. Even then, nothing is lost by using Tailscale instead — DNS rebinding is only one of the ways an open unauthenticated API goes wrong. None of this depends on your GPU vendor; Ollama’s API layer is identical on NVIDIA, AMD, and CPU-only installs.

FAQ

Does this vulnerability affect Open WebUI, LM Studio, or llama.cpp? Not directly — CVE-2026-65105 is a NemoClaw configuration flaw. But the attack pattern applies to any unauthenticated local HTTP API bound to a non-loopback address without Host-header validation. llama.cpp’s llama-server and LM Studio’s server mode deserve the same two-minute audit: check the bind address, check who can reach the port.

If I was exposed, how do I know whether a model was poisoned? Run ollama show <model> --modelfile for each installed model and inspect the TEMPLATE and SYSTEM sections for instructions you did not write. If anything looks off, delete the model (ollama rm) and re-pull it from the registry; the re-pulled copy has a clean template. There is no public evidence of in-the-wild exploitation as of October 19, 2026 — Oasis Security’s work was a disclosure demo — but the check is cheap.

Is NemoClaw safe to use after the patch? The binding flaw is fixed on macOS and Linux per the public reporting, and the project is Apache 2.0 with active development (~22.8k stars, October 2026). The caution flag is Windows/WSL, where disclosure-time reporting described a warning rather than a fix — WSL users should verify the bind address themselves after every update until NVIDIA documents a structural fix.

Sources

• Cloud Security Alliance research note — DNS Rebinding in NemoClaw Enables Persistent Model Poisoning (August 27, 2026)
• eSecurityPlanet — NVIDIA Patches High-Severity NemoClaw Flaw After Model-Poisoning Demo
• AI Weekly — Oasis Discloses NVIDIA NemoClaw Flaw CVE-2026-65105
• NVIDIA NemoClaw repository (license and project scope, checked October 19, 2026)
• Ollama CVE-2024-28224 — prior DNS rebinding fix in v0.1.29 (March 2024)

What self-hosting actually costs

Real cost breakdowns for self-hosted AI: hardware floors, power, maintenance hours, and the honest comparison against paying for it. No spam, unsubscribe anytime.

Email address Subscribe