I scanned the internet for Ollama servers. Here's what I found.

4 min read
ollama self-hosting security AI infrastructure open source networking
==============================

by LATTE

I built a small scanner. Nothing fancy — just a tool that checks whether a given IP is running an Ollama instance and whether its API is publicly reachable. I wasn’t expecting to find much. I was wrong.

Scattered across the internet, there are Ollama servers — real ones, running real models — that are completely open. No authentication. No firewall rule. Just a raw API endpoint, accepting requests from anyone who knows where to look.

Some of them are running on paid Ollama Cloud subscriptions.

How the scanner works

Ollama exposes a simple REST API. The health endpoint is just a GET request:

GET http://<host>:11434/
→ "Ollama is running"

GET http://<host>:11434/api/tags
→ lists available models

That’s it. If a server responds to those two requests, it’s open. No login required. The scanner iterates through a list of IPs, checks the port, and logs what it finds. Straightforward to build, straightforward to run.

What I found

Open Ollama servers, a fair number of them. Some are clearly personal machines that someone left exposed — probably didn’t think about it, or didn’t know the default port binds to all interfaces. But others show signs of being intentional deployments: they’re stable, they respond fast, they have multiple large models loaded.

The interesting wrinkle: some of these appear to be Ollama Cloud subscribers. Meaning someone is paying for compute, and then accidentally (or naively) making that compute publicly available. Anyone who finds the endpoint can use it — for free, on someone else’s bill.

I connected to one of these from an isolated environment out of curiosity. It worked. I immediately disconnected and didn’t use it for anything. The point was to confirm it was real, not to exploit it.

To be clear: I’m not publishing IPs. This post isn’t a guide to finding or using these servers. If you’re technically inclined, you already know how to find them. If you’re not, you don’t need to.

Why this happens

Ollama’s default configuration binds to 127.0.0.1 — localhost only. So if you’re running it locally, you’re fine by default. The problem happens when people deploy it on a VPS or cloud VM and either don’t check the bind address, or explicitly expose it without adding any auth layer. The Ollama API has no built-in authentication. It’s designed to be a local tool.

Docker makes this worse in a subtle way. If you expose port 11434 in your docker run or compose file without binding it to a specific interface, Docker’s networking will happily route traffic from the outside world to your container — bypassing your system firewall entirely in some configurations.

Is it safe to use one?

Probably not. You don’t know who controls the server, what’s logged, or whether the model has been tampered with. Running arbitrary prompts through an unknown endpoint is not something I’d recommend. Even setting aside the ethical dimension of using someone else’s resources without permission, the practical risk isn’t worth it.

If you’re running Ollama

A few things worth checking:

  • Make sure Ollama is bound to 127.0.0.1 and not 0.0.0.0. If you need remote access, put it behind a reverse proxy with authentication (Nginx + Basic Auth, or something like Authelia if you want to go further).
  • Don’t expose port 11434 directly to the internet.
  • If you’re using Docker, be explicit about your port bindings — 127.0.0.1:11434:11434 instead of just 11434:11434.

The OLLAMA_HOST environment variable controls what Ollama binds to. Set it to 127.0.0.1:11434 if you want to be explicit.

Final thought

I built this scanner out of curiosity, not malice. What I found was genuinely surprising — not because the vulnerability is exotic, but because it’s so mundane. A default port, no auth, a public IP. That’s all it takes.

The internet is full of things that are open that probably shouldn’t be. Ollama servers are just the latest example. If you’re deploying AI infrastructure, treat it like any other service: assume someone is going to try to reach it, and make sure they can’t.

Back to blog