Skip to main content
In January 2026, SentinelLABS and Censys published research mapping roughly 175,000 internet-exposed Ollama hosts across about 130 countries — SentinelOne’s writeup is the primary source; the numbers here have also circulated via The Hacker News and SecurityWeek. Researchers reported that roughly half of the exposed hosts advertised tool-calling support — meaning code execution, not just chat. That is not a vulnerability in Ollama. It is a default that a lot of people never change.

​
The failure mode

Ollama listens on 127.0.0.1:11434 by default — loopback only, unreachable from outside the machine. To reach it from another device on your network (or from a phone, a second computer, a coding agent running elsewhere), the common fix is:
That single environment variable changes the bind address from loopback to all interfaces. Combine it with a router port-forward, a cloud VM’s public IP, or a firewall rule opened “just for now” — and port 11434 is reachable from the entire internet, not just your LAN. There’s no authentication in front of it by default, so anyone who finds the port can call the API directly: list models, run inference, and, on hosts advertising tool-calling, potentially trigger code execution through the model. This is exactly the pattern mass-scanning tools like Shodan and Censys are built to find. It doesn’t take a targeted attack — it takes a port scan.
This is a configuration problem, not a defect in Ollama. The same failure mode — bind-to-all-interfaces plus an open or forwarded port plus no auth in front of it — applies to any local model server, not just Ollama.

​
Why “just add auth” doesn’t fully solve it

Putting a reverse proxy with basic auth in front of 0.0.0.0:11434 helps, but it doesn’t remove the underlying condition: the port is still listening, and something in your network path still has to be reachable from the outside for that proxy to work. Every inbound-facing component — the proxy, the firewall rule, the port forward, the TLS cert — is one more thing that has to stay correctly configured forever. Misconfigure any of them once, or roll one back during debugging, and you’re back to an open port.

​
The alternative: never have an inbound port at all

Tokios takes a different approach: the tokios-connector you run next to your model never listens for inbound traffic. It opens a single outbound wss:// connection to https://api.tokios.com — the same direction your browser already uses to load a webpage — and Tokios routes requests back over that connection. There is no port to forward, no firewall rule to open, and nothing bound to 0.0.0.0. Every request that does reach your model has to carry a scoped sk-tok-… API key, checked before Tokios ever forwards it down the tunnel to your connector. Keys can be scoped to specific deployments with model-name patterns, rotated, disabled, or deleted — and a revoked key stops authenticating immediately. To be precise about what this does and doesn’t mean: an outbound-only connector has no inbound surface to expose in the first place. That is a structural difference in the connection model, not a security guarantee. Tokios isn’t claiming to prevent every possible misuse of a model you expose through it — a leaked API key is still a real risk, same as a leaked password anywhere else. The point is narrower and more mechanical: there’s no listening port for a scanner to find, because there never was one.
If you’re running Ollama with OLLAMA_HOST=0.0.0.0 today for remote access, that’s the exact pattern behind the 175,000-host number. Put your model back on 127.0.0.1 and reach it through an outbound-only connector instead — see Ollama remote access for the swap.

​
What this looks like in practice

1

Run Ollama on loopback, like it does by default

No OLLAMA_HOST override, no bind-to-all-interfaces flag.
2

Pair the connector

tokios-connector dials out to https://api.tokios.com and waits for you to approve it in the console. Nothing about this step opens a port on your machine or your router.
3

Call your model from anywhere

The request has to present a valid, scoped sk-tok-… key or it never reaches your connector.
This is also exactly the situation for anyone behind carrier-grade NAT (CGNAT), where port forwarding isn’t just discouraged — it’s structurally impossible because your router has no public IP to forward to. See Serve a local LLM from behind CGNAT for why that’s true and how the same outbound-only connection sidesteps it.

​
The takeaway

The 175,000-host figure is a scan result, not a prediction about any specific server. But the pattern behind it is simple and worth remembering regardless of the exact count: inbound reachability plus no auth is the whole problem. Removing the inbound part removes an entire category of “how did they even find this” incidents, because there’s nothing listening to find.

Quickstart

Pair a connector, register a model, and send your first request.

Ollama remote access

Move an already-exposed Ollama install back to loopback and reach it through Tokios instead.

How Tokios routes requests

See the outbound-only architecture end to end.