A local service can be unreachable from the internet but still accessible through a browser on the same machine

That was the route documented in a security advisory for OpenClaw, the local AI assistant previously called Moltbot and ClawdBot. The vulnerability did not begin with a public server. It began with a link that changed where OpenClaw's control interface connected.

The maintainer's advisory, published on 31 January 2026, described a crafted link that could expose the user's stored access token. The researcher then demonstrated how the browser could use that token to reach the local gateway, change its protections and run a command on the host.

This particular chain of product flaws is not evidence that every local agent can be taken over from a webpage, but it does show why localhost describes a route rather than an identity.

The Browser Was the Bridge

The OpenClaw sequence is worth looking into because shorthand can make a poor control choice look good enough.

First, the attacker needed the control interface to disclose its token. The attacker-selected gateway address and automatic connection caused that leak. Then the attacker's page used the browser to open a separate WebSocket connection to the service on the victim's own machine. Missing Origin validation allowed that connection, and the stolen token authenticated it.

The local gateway's legitimate authority supplied the consequence. The demonstrated operator scopes let the researcher disable command confirmation, run commands outside the configured container, and execute a system command.

Binding the service to loopback did not stop a browser-originated connection. Authentication did not help once the interface had sent its token to an attacker. Sandboxing did not hold once the same administrative API could change its settings.

The controls need to fail separately: validate connection destinations and browser origins; protect the token; prevent an authenticated agent session from weakening its own containment; and keep consequential permissions narrower than the user's standing access.

This remains an interface-authentication and privilege-chain failure. Hostile content delivered after a valid login is another problem. A correctly authenticated agent can still read a malicious document or webpage and mistake its content for an instruction. Fixing the OpenClaw vulnerability would not, by itself, solve that prompt-injection risk.

Public Ollama Servers Were a Separate Exposure

Two days before the OpenClaw advisory, SentinelLABS and Censys published a large measurement of internet-reachable Ollama services.

Over 293 days, the researchers recorded 7.23 million observations from 175,108 unique Ollama hosts across 130 countries. That is a cumulative count across the measurement period, not 175,108 servers proven to be online at the same moment. A persistent core of about 23,000 hosts generated most of the observed activity.

The study also found that more than 48% of observed hosts advertised tool-calling capability in their API metadata. The smaller combination of completion and tools appeared on 38% of hosts. These figures describe declared model capability. They do not prove that an external tool was attached, that code execution was available, or that the host had been compromised.

Ollama binds to 127.0.0.1 by default. Public exposure requires a deployment change, such as binding to 0.0.0.0 or another public interface. The scan therefore described operators who had made their services internet-reachable, deliberately or accidentally. It was not evidence that a remote attacker had used a browser to reach a default local Ollama installation.

The distinction matters because the remedies differ. The OpenClaw case involved an attacker using the browser as a bridge to a loopback service. The Ollama population was directly reachable from the internet and needed the controls expected of any public service: explicit exposure decisions, authentication, monitoring, patching and an identifiable owner.

Final Perspective

localhost should not reassure on its own. In the OpenClaw chain, the browser already sitting on the machine became the route into the local service, and the gateway's legitimate authority supplied the consequence. The word described where the service listened; it did not establish who was calling.

Self-hosting can still be a sound choice for privacy, availability, or cost, but it comes with a cost: it transfers exposure and patching decisions to the operator. The Ollama study shows why that distinction matters: binding a service to a public interface is a separate deployment choice. “Local” is an architectural claim to verify, not a security property to assume.