DevBlacksmith

Tech blog and developer tools

← Back to posts

175,000 Ollama Servers Are Exposed to the Internet — And Hackers Are Selling Access

175,000 Ollama Servers Are Exposed to the Internet — And Hackers Are Selling Access

The Scale of the Problem

A joint investigation by SentinelOne SentinelLABS and Censys revealed something alarming: between October 2025 and January 2026, approximately 175,000 unique Ollama instances were found exposed to the public internet across 130 countries.

Of those, roughly 23,000 remained persistently online — always available, always unprotected, always exploitable.

China accounts for over 30% of exposures, followed by the United States, Germany, France, South Korea, India, Russia, Singapore, Brazil, and the UK.

These aren't enterprise deployments with security teams. Many are running on residential networks, developer laptops, and personal servers — completely outside any governance or monitoring framework.

What Is Ollama?

For those unfamiliar: Ollama is an open-source framework for running large language models locally. It lets you download and run models like Llama, Mistral, Gemma, and others on your own hardware — no cloud API needed.

It's become massively popular because it's simple. Install it, pull a model, and you're running AI locally in minutes. The promise: your data stays on your machine.

The problem: by default, Ollama binds to 127.0.0.1:11434 (localhost only). But many users change this to 0.0.0.0 to access it from other devices on their network — and in doing so, expose it to the entire internet with no authentication.

# Default (safe) — only accessible from your machine
OLLAMA_HOST=127.0.0.1:11434

# What people do (dangerous) — accessible from anywhere
OLLAMA_HOST=0.0.0.0:11434

That single configuration change turns a private AI server into a public one. And Ollama ships with no authentication mechanism by default.

What Attackers Are Doing With Exposed Servers

LLMjacking

The most common attack is LLMjacking — hijacking someone else's LLM infrastructure to use their compute for free. The victim pays the electricity and hardware costs while the attacker gets unlimited AI processing.

Researchers documented Operation Bizarre Bazaar, a campaign between December 2025 and January 2026 that captured 35,000 attack sessions. The operation was traced to a threat actor using aliases "Hecker," "Sakuya," and "LiveGamer101" who built an entire commercial marketplace around stolen AI compute.

The silver.inc Marketplace

The attacker built silver.inc — described as a "Unified LLM API Gateway" — that:

  1. Scans for exposed Ollama instances, vLLM servers, and OpenAI-compatible APIs without authentication
  2. Validates endpoints by assessing response quality and model capabilities
  3. Packages and resells access at discounted rates

This is the first documented LLMjacking marketplace with complete attribution. It's essentially a black market AWS for stolen AI compute.

Beyond Compute Theft

LLMjacking is just the beginning. Researchers found that 48% of exposed hosts advertise tool-calling capabilities — meaning the LLM can execute code, access APIs, and interact with external systems.

As the researchers noted: "A text-generation endpoint can produce harmful content, but a tool-enabled endpoint can execute privileged operations."

Other risks include:

  • Data exfiltration — If your Ollama instance has access to local files (many do), attackers can extract them
  • Prompt injection — Tricking the model into executing malicious actions through crafted inputs
  • Proxy abuse — Using exposed instances to generate spam, disinformation, or phishing content
  • Model poisoning — On instances with write access, attackers can tamper with model files

Additionally, 201 hosts were found running uncensored prompt templates that remove all safety guardrails — making them particularly valuable for generating harmful content.

Why This Keeps Happening

The pattern is clear: AI tooling spreads faster than security practices.

Developers and hobbyists install Ollama because it's easy and exciting. The documentation focuses on getting started fast. Security configuration is an afterthought — buried in advanced docs that most users never read.

This is exactly what happened with:

  • Redis — Tens of thousands exposed to the internet with no auth
  • MongoDB — Massive data breaches from publicly accessible instances
  • Elasticsearch — Exposed clusters leaking millions of records
  • Docker — Unauthenticated Docker daemons used for cryptomining

Ollama is the latest entry in the "cool tool, terrible defaults" hall of fame.

How to Secure Your Ollama Installation

If you're running Ollama, here's how to lock it down:

1. Keep It on Localhost

Unless you have a specific reason to expose it, keep the default binding:

OLLAMA_HOST=127.0.0.1:11434

If you need remote access, use an SSH tunnel instead:

# From your remote machine, tunnel to the Ollama host
ssh -L 11434:localhost:11434 user@your-ollama-server

# Now access Ollama at localhost:11434 on your remote machine

2. Put It Behind a Reverse Proxy With Auth

If you must expose Ollama to your network, put it behind nginx or Caddy with basic auth:

server {
    listen 443 ssl;
    server_name ollama.internal;

    location / {
        auth_basic "Restricted";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:11434;
    }
}

3. Firewall Rules

Restrict access to specific IPs:

# Linux (iptables) — only allow your IP
iptables -A INPUT -p tcp --dport 11434 -s YOUR_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 11434 -j DROP

4. Run It in a Container

Docker with explicit network controls limits the blast radius:

docker run -d \
  --name ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama

Note the 127.0.0.1: prefix — this binds only to localhost, not all interfaces.

5. Disable Tool Calling If You Don't Need It

If you're just using Ollama for text generation, disable tool-calling capabilities to reduce the attack surface.

6. Monitor Access Logs

Check who's connecting to your instance. Unexpected traffic from foreign IPs is a red flag.

Check If You're Exposed Right Now

Quick test from your local machine:

# Try to reach your Ollama instance from outside
curl http://YOUR_PUBLIC_IP:11434/api/tags

If that returns a list of models, you're exposed. Fix it immediately.

You can also check Shodan for your IP to see if your instance has been indexed.

The Takeaway

Running AI locally is great for privacy — in theory. In practice, a misconfigured Ollama server gives attackers more access than a cloud API ever would: free compute, no rate limits, no audit trail, potential file system access, and tool-calling capabilities.

The rule is simple: treat self-hosted AI infrastructure with the same security posture as any other internet-facing service. Authentication, encryption, network segmentation, and monitoring. No exceptions.

Your Ollama server shouldn't be someone else's free API.


Sources