2026-07-28 · ~6 min read

Is my Ollama exposed? How to check, and how to lock it down

Earlier this year, researchers from SentinelLABS and Censys counted about 175,000 Ollama servers answering on the public internet. Most of them are there by accident. Someone runs the install, the server binds to every interface by default, and nobody ever asks the question in the title of this post.

I know this because I run a small exposure checker, and because I put a deliberately open Ollama box on the internet to see what would happen. Bots found it within the hour.

What a stranger can do with your Ollama

No exploit needed. The API just answers. Anyone who finds your server can:

• Run inference on your hardware. Free GPU compute for them, a power bill and a melted queue for you. People call this LLMjacking, and it is not theoretical. Sysdig caught it happening to a real server in June 2026.
• List your models (GET /api/tags), copy them (/api/pull from your box to theirs), or just delete them.
• Read what is in memory if your prompts say anything interesting, which prompts usually do.

If your Ollama is also old, it gets worse. CVE-2024-37032 (fixed in 0.1.34, back in 2024) was remote code execution. Anything unpatched since then is not a server, it is a gift.

The 60 second check

From a machine that is not on your network (your phone on mobile data works):

curl -m 10 http://YOUR.SERVER.IP:11434/api/version

If that answers with a version string, you are exposed. For extra confirmation:

curl -m 10 http://YOUR.SERVER.IP:11434/api/tags

That second one lists your models. If you can see them, so can everyone else.

If you would rather not do this by hand, the checker does exactly these probes plus the rest of the usual suspects (n8n, vLLM, Langfuse, ComfyUI, Open WebUI, Ray), and grades what it finds.

Three ways to fix it, in order of preference

1. Bind to localhost. If you only use Ollama from the machine it runs on, this is the whole fix:

# systemd: sudo systemctl edit ollama
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

Then sudo systemctl restart ollama. Done. Nothing else to do, ever.

2. Reverse proxy with auth. If you genuinely need it reachable (a small team, a second machine), put nginx or Caddy in front with basic auth or mTLS, and keep 11434 firewalled from everything except the proxy. Do not skip the auth part. A proxy without auth is just a fancier way to be exposed.

3. Firewall. If you cannot touch the config, at least close the port:

sudo ufw deny 11434/tcp

This is the weakest of the three because it tends to get "temporarily" reopened. Treat it as defense in depth, not as the fix.

Verify you are actually done

Run the same curl from outside again. You want a timeout or a connection refused. A 403 from your proxy is also fine. What you do not want is that version string smiling back at you.

The full fix card I ship with the checker is at /fixes/ollama-exposed if you want the short version to paste into a terminal. And if your box runs other self-hosted AI tools, it is worth scanning for those too. n8n has its own way of going wrong, which is a separate post.