152,137 exposed Ollama servers found in year-long scan

Researchers at Nankai University spent a full year probing the public internet for Ollama servers and counted 152,137 exposed instances of its unauthenticated API. Almost none of the vulnerable ones were ever patched — which makes this the self-hosting security story of the week for anyone running open-weight models outside a provider cloud.

Key facts

• 152,137 cumulative IPs served an exposed Ollama API at some point between February 2025 and February 2026, across 362 observation days and roughly 4.8 million IP-by-day observations.
• Only 0.43% to 2.90% of below-fix IPs upgraded in place across the five tracked CVEs — in-place patching is the exception, not the rule.
• The top five countries and regions account for over 70% of weighted observations, and cloud and hosting providers dominate the top ASNs.
• Ollama ships its REST API on port 11434 without built-in authentication, and common Docker images and LAN-access tutorials can bind it to a public interface.
• A separate industry investigation summarized by Indusface claims more than 175,000 publicly exposed instances over a 293-day window — a vendor-reported figure consistent with the paper, but still a claim, not a measurement.

What happened

The paper, "Ollama in the Wild," by Zuyao Xu, Xiang Li, Yuqi Qiu, and Lu Sun of Nankai University, was posted to arXiv on September 7, 2026 and accepted to the 2026 ACM Internet Measurement Conference in Karlsruhe this October. It is the first longitudinal study of self-hosted model serving as an internet-wide phenomenon: daily active probing with the XMap prober from February 14, 2025 to February 13, 2026, enriched with GeoIP and ASN data, reverse-DNS records, adjacent port-443 observations, and survival analysis.

The mechanism behind the numbers is mundane, which is exactly the point. Ollama's API on port 11434 carries no built-in authentication, so any deployment path that binds the service to a public interface — a Docker container with published ports, a follow-the-tutorial remote-access setup, a cloud VM without a firewall rule — puts a fully capable inference endpoint on the open internet. The authors document disclosed vulnerabilities in that surface including CVE-2024-37032 reported by Wiz Research, CVE-2024-39719 through CVE-2024-39722 reported by Oligo Security, and CNVD-2025-04094 — then show that exposure persists regardless: just over a quarter of the observed IPs (26.4%) appeared for a single day, meaning the bulk of the surface is long-lived, and the patch rate rounds to zero.

Independent corroboration exists but stays in the vendor-claim category. Cisco published a Shodan-based methodology for systematically finding publicly exposed Ollama servers, and the industry scan summarized by Indusface claims 175,000-plus exposed instances. DeAI has not independently verified either vendor figure; what is verified is the peer-reviewed Nankai measurement, published under a CC BY 4.0 license with a citable DOI (10.1145/3777912.3839823).

Why it matters

Builders move workloads to self-hosted open-weight models for the strongest privacy reason there is: prompts never leave infrastructure they control. An exposed port 11434 inverts that bargain completely. Anyone on the internet can query the endpoint, inspect which models are loaded, submit prompts that consume the operator's GPU budget, and — depending on version and configuration — exploit known remote flaws. The paper's concentration finding sharpens the point: exposure clusters in cloud and hosting ASNs and a handful of regions, which means this is mostly not hobbyists behind home routers but rented infrastructure with a missing firewall rule.

There is a constructive side to that concentration. Because the top autonomous systems and a small set of geographies account for most of the surface, the authors argue provider-level mitigation is within reach — cloud firewalls that default port 11434 to closed, image defaults that bind to localhost, tutorials that teach the reverse-proxy pattern. For teams choosing where to run models today, the takeaway is narrower and immediate: treat every self-hosted endpoint as internet-facing until proven otherwise, and close this specific hole before optimizing anything else.

Background

This is not a new vulnerability class, and DeAI's existing self-hosting coverage already points at the fix. Our guide to moving from Ollama to a private endpoint walks through putting authenticated, network-restricted access in front of local models, and our self-hosting versus API cost breakdown frames the real economics once hardening labor is included. The exposure study adds the missing empirical leg: the community's working assumption that "everyone firewalls their box" is, at internet scale, false.

The finding also rhymes with the week's other privacy stories. The same builders who self-host to escape provider retention policies — the enterprise backlash over Anthropic's 30-day Fable logging is still unfolding — inherit the full operational burden of that choice. Confidential-computing approaches like TEE-backed inference raise the ceiling on what verifiable privacy can look like, but no enclave helps a deployment whose API port answers the whole internet. And the zero-retention API explainer remains the alternative for teams that want private-ish inference without operating infrastructure at all.

What's next

The authors present the full results at ACM IMC '26 in Karlsruhe, October 12–16, where the Q&A with network operators may reveal whether any provider has started firewall-default mitigations. Watch three things: whether Ollama changes its bind-by-default or authentication posture in response, whether major clouds add port-11434 defaults or detection, and whether follow-up scans show the patch rate moving off near-zero. None of those has happened yet — which is precisely why the hardening checklist in this article's FAQ is the actionable part of the story.