Local AI Agent Security: What CVE-2026-65105 Says About Every Self-Hosted Model

Local ai agent security has a founding assumption that almost nobody states out loud, and CVE-2026-65105 is what happens when it fails. The assumption is that a model running on your own machine is not exposed to anything. The moment you start a local model server, you have started a network service, and almost nobody treats it like one.

Oasis Security disclosed the flaw on August 25, 2026. NVIDIA’s NemoClaw wrapper started the Ollama model server bound to all network interfaces with no authentication. A DNS rebinding attack launched from an ordinary webpage could then reach that server and rewrite the model’s chat template, appending attacker instructions to every system message the model ever sees again. This piece covers what the flaw is, why a poisoned template is worse than a prompt injection, the detail that makes this a pattern rather than an incident, why the published version records disagree, how to harden a self-hosted model server, and how you would ever notice. For what the underlying tool is, start with our guide to Ollama.

What the flaw actually is

The NVD entry describes it in one sentence: "NVIDIA NemoClaw for Linux contains a vulnerability in its inference server setup, where a remote attacker may access the inference service without authentication." It carries a base score of 8.1, rated High, under CWE-306, Missing Authentication for Critical Function.

The mechanism has three parts, and none of them is exotic.

First, the bind address. NemoClaw started Ollama with OLLAMA_HOST=0.0.0.0:11434, which listens on every network interface rather than only the loopback address, even though the surrounding documentation talked about localhost.

Second, the missing authentication. Ollama’s API has no authentication layer. Its API documentation describes endpoints for creating and inspecting models with no mention of keys, tokens or credentials anywhere. Protection came from origin and Host header checks instead, and those checks were skipped when the server was bound to a non-loopback address.

Third, DNS rebinding, which is how a webpage reaches a service on your own machine. An attacker points a domain they control at their own server, serves you a page, then re-resolves that same domain to 127.0.0.1. The browser keeps treating the requests as same-origin because the hostname has not changed, and the requests land on your local port.

Put those together and any page you visit could talk to your model server as though it were a local application.

Why a poisoned chat template is worse than a prompt injection

This is the part that separates the incident from ordinary prompt injection, and it is worth being precise about.

Ollama’s /api/create endpoint accepts a template field, documented as "the prompt template for the model." That template governs how every message, including system messages, is assembled before the model sees it. A companion endpoint, /api/show, returns the existing template. So an attacker can read the current template, insert instructions into it, and write it back.

What that buys the attacker is persistence at the wrong layer. The injected text is not in the conversation, so clearing the chat does not remove it. It is not in the system prompt, so an agent that supplies its own system prompt on every run still gets the attacker’s text appended. It is not in the API response, so anything consuming the API sees normal output. As the disclosure coverage put it, the payload "lives in the model definition, well below the conversation state an operator can reset."

Most agent security guidance assumes the untrusted input arrives in the conversation. Here it arrives in the model’s own definition, underneath everything the operator controls. Our piece on agentic browser security covered the same category of failure from the browser side: a boundary people assumed was structural turning out to be a judgment call.

Ollama fixed this in 2024, and a wrapper undid it in 2026

Here is the detail that makes this a pattern worth writing about rather than a single vendor’s bug.

Ollama already had a DNS rebinding vulnerability. CVE-2024-28224, scored 6.6 Medium, described "a DNS rebinding vulnerability that can inadvertently allow remote access to the full API." It was fixed in Ollama 0.1.29, released in March 2024.

The 2026 flaw is the same attack class against the same software, roughly two and a half years later, scored higher. Ollama’s fix was not reverted. It was bypassed by configuration, because the Host and Origin validation that fix relies on is skipped whenever the server is bound to a non-loopback address. A wrapper set one environment variable and the protection stopped applying.

That is the generalizable lesson and it is not about NVIDIA. A hardening measure whose effectiveness depends on a default is only as strong as the last piece of software allowed to change that default. Installers, wrappers, container images, orchestration templates and quickstart scripts all change defaults, usually to make something work on the first try, and usually without saying which protection they just turned off.

Why the published version numbers disagree

Anyone trying to work out whether they are exposed will hit a genuine problem, so it is worth stating plainly rather than papering over.

The NVD entry scopes the CVE to NemoClaw for Linux, versions 0 through 0.0.25. Reporting based on the researchers’ account, including The Hacker News, says v0.0.35 addressed the issue on macOS and Linux, and that there was no fix on the Windows and WSL path at disclosure, where a Windows installation shipped with a warning instead. Those records do not reconcile cleanly, and the CVSS vector adds a third wrinkle: it is scored AV:A, adjacent network, which reads oddly for something reachable from any webpage a user happens to open.

The practical response is not to resolve the discrepancy from news coverage. It is to check your own installed version against NVIDIA’s advisory directly, and, if you are on Windows or WSL, to assume you need to apply the mitigations below yourself rather than waiting for a version number to make the problem go away. Oasis reported the issue to NVIDIA’s PSIRT before publishing, and no exploitation has been reported.

Local AI agent security starts by admitting it is a network service

Strip out the specifics and what remains is a posture problem that predates this CVE and will outlast it.

Running a model locally feels like running an application. It is not. It is running a daemon that listens on a port, speaks an unauthenticated HTTP API, and accepts commands that change how the model behaves. Every property you would demand of a service you deployed for other people applies, and almost none of it is applied by default.

Consider what the standard local setup actually is. No authentication. A listening port. An API that can create and modify models. No audit log. No alerting. Frequently no idea which version is installed, because it arrived as a dependency of something else. If a colleague described that as a production deployment you would stop them. It gets a pass because it is on a laptop, and "it is only on localhost" is doing a great deal of unearned work in that sentence, as DNS rebinding demonstrates. Our overview of running local AI models covers why so many teams end up here.

How to harden a self-hosted model server

Six measures, roughly in order of how much protection they buy per minute spent.

Bind to loopback and verify it. Set OLLAMA_HOST=127.0.0.1:11434 rather than 0.0.0.0. Then confirm it, because the whole point of this CVE is that something else set it for you. ss -ltnp or lsof -i :11434 will tell you what the process is actually listening on, which is the only answer that counts.

Put authentication in front of it. The API has none. If anything other than a process on the same machine needs access, front it with a reverse proxy that requires a credential. Do not expose the raw port and rely on network position.

Treat the port as sensitive at the firewall. Deny inbound 11434 at the host firewall. This is cheap, and it limits the blast radius of the next wrapper that changes your bind address.

Restrict outbound access too. A poisoned model that can reach the internet is a different problem from one that cannot. Egress filtering on the machine running the agent limits what injected instructions can accomplish.

Pin and record versions. Know which version of the server and which wrapper you are running. Much of the difficulty this week came from people being unable to answer that question quickly.

Audit your model templates. This is the specific one. Pull the template for each installed model and compare it to what the model shipped with. On Ollama that means reading the template back through /api/show and diffing it against a known-good copy you stored yourself.

How you would ever notice

The uncomfortable answer is that with no preparation, you very likely would not.

A poisoned template produces plausible output. There is no error, no crash, no unusual latency, and no visible change in the API response. The model simply follows an extra instruction that nobody in the conversation wrote. If that instruction says to insert a particular link occasionally, or to quietly favor one vendor, or to omit a category of warning, it can operate for months inside output that looks entirely normal.

So detection has to be set up before you need it. Store a hash of each model’s template at install time and re-check it on a schedule, which turns an invisible modification into a failed comparison. Watch for anything unexpected listening on your inference port. And apply the same skepticism to model output that you would to any other unsigned input, because the assumption that the model’s own definition is trustworthy is exactly what this attack breaks. That maps onto the broader problem we covered in AI safety guardrails blocking defenders: controls that assume the wrong threat model tend to fail quietly rather than loudly.

Frequently Asked Questions