36,769 AI Services Found Exposed Across the Public Internet

Public reachability spans the AI supply chain

A study published on September 11 identified 36,769 publicly reachable AI endpoints, ranging from local model servers to automation platforms and vector-store consoles.

Researchers at Mysterium VPN found the systems by querying the Netlas internet-scanning index and matching service-specific fingerprints. Only 2.02% of the identified endpoints returned an HTTP 401 or 403 response, the status codes used as evidence of an authentication barrier.

That does not mean every other service permitted unrestricted access. Login pages can return HTTP 200, while authentication may be enforced elsewhere in an application. The figure instead shows that most deployments lacked a detectable network-layer challenge at the scanned endpoint.

The research measured observable exposure, not successful intrusion. The researchers did not retrieve documents, inspect chat histories, read credentials, run models, exploit vulnerabilities, or publish hostnames and IP addresses.

The total is also a lower bound. Internet-scanning indexes do not cover every port or host, and strict fingerprints exclude systems that cannot be confidently attributed to a particular product.

Still, the distribution shows how self-hosted AI infrastructure can expose several distinct assets: GPU capacity, workflow credentials, connections to business systems, and the private data used for retrieval-augmented generation.

Model servers dominate the exposed population

Open WebUI was the largest product population in the dataset, with 18,529 reachable instances. Only one returned an HTTP authentication challenge.

The researchers also identified:

• 4,880 vLLM endpoints, three of which returned an authentication challenge;
• 150 LocalAI endpoints, none of which returned a challenge;
• 69 llama.cpp endpoints, none of which returned a challenge.

These numbers cannot establish that every installation was anonymously usable. An Open WebUI login interface, for example, may respond with HTTP 200 while still requiring credentials before exposing conversations or model functions.

Ollama provided stronger evidence because its root endpoint presents the recognizable text Ollama is running without requesting authentication. Mysterium found 6,935 hosts with that fingerprint, including 6,046 that explicitly responded with HTTP 200.

An exposed Ollama API can reveal installed models and allow an external user to submit inference requests using the operator’s hardware. Attackers can consequently consume GPU time and electricity without compromising the host in the conventional sense.

This resource abuse is commonly described as LLMjacking. It can produce costs, degrade service for legitimate users, and tie the operator’s infrastructure to content generated by an unknown third party.

A separate SentinelOne and Censys study published in January counted approximately 175,000 exposed Ollama hosts across 130 countries. Nearly half supported tool-calling features that could execute code, invoke APIs, or communicate with external systems. Differences in scanning coverage and fingerprint requirements explain why that total was substantially larger.

Mysterium additionally observed 22,024 responses on Ollama’s default port, 11434. Those systems were excluded from the primary count because a port alone does not prove which application is listening. Of those responses, 4,136, or 18.8%, originated in the United States.

The researchers attempted a broader country breakdown but discarded it after rate limits made the results unreliable for several major countries.

Agent platforms can expose more than compute

The study found 5,223 publicly reachable agent-building and workflow platforms. Identified products included Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow, and Open WebUI Pipelines.

These applications can create a larger security impact than an isolated inference server. Their purpose is to connect models with data and actions, often by storing or referencing OpenAI API keys, database credentials, Slack tokens, CRM passwords, and webhook secrets.

A workflow platform may also have permission to query production databases, update customer records, access source-code repositories, send messages, or trigger other automation. Exposure therefore places both secrets and authorized execution paths closer to an attacker.

Mysterium identified 1,341 reachable Flowise instances. None returned a 401 or 403 authentication challenge, although that measurement alone does not prove the absence of application-level login controls.

Flowise also has a separate software risk. CVE-2026-40933 is a critical MCP adapter vulnerability through which an authenticated attacker can execute arbitrary commands. It carries a CVSS score of 9.9 and the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

The issue was fixed in Flowise 3.1.0. Administrators should upgrade to that version or later.

Internet exposure does not demonstrate that any detected Flowise system runs a vulnerable release, and the flaw still requires authenticated access. However, a publicly reachable deployment provides attackers with more opportunities to obtain or reuse credentials and then target the command-execution path.

Leaked tokens make exploitation unnecessary

The risks around n8n illustrate why defenders cannot focus exclusively on software flaws.

In an analysis published in August, GitGuardian researchers examined n8n API tokens exposed in public GitHub commits. They identified 4,576 unique tokens associated with 1,255 hostnames.

Of those hosts, 896 were reachable during testing. At least one leaked token worked against 321 instances.

In such cases, the attacker does not need a vulnerability. A valid token may provide direct access to workflows and their integrations, depending on its privileges and the configuration of the affected instance.

This makes n8n and Flowise deployments connected to production environments high-value credential stores. A token leaked through source code can become the entry point, while a publicly accessible control plane gives the attacker somewhere to use it.

Defenders should review repositories and commit histories, not just the current version of a project. Removing a secret from the latest revision does not invalidate copies retained in earlier commits, forks, logs, or caches. Any credential suspected of exposure must be rotated.

Vector stores create a separate data-exposure risk

Mysterium counted 920 reachable vector-store endpoints, almost all presenting Attu management consoles for Milvus. This category is particularly incomplete because the scanning source did not cover the native ports used by Qdrant and Milvus databases.

A vector database can therefore remain publicly reachable without appearing in the total.

These systems store embeddings and associated content used by AI applications to retrieve relevant information. Depending on the deployment, that material may include internal documents, support tickets, customer records, operational instructions, or private knowledge-base entries.

An exposed management console and an exposed native database interface also represent different discovery problems. Security teams that scan only conventional web ports may find Attu while missing the underlying database, or vice versa.

The study did not inspect collections or retrieve records, so it does not establish that data was accessible from any of the 920 endpoints. It does show that management surfaces were visible from the public internet.

Defenders should reduce exposure before investigating compromise

Organizations should begin by inventorying model servers, agent platforms, workflow engines, vector databases, and related management consoles. Cloud assets and temporary AI experiments deserve particular attention because services can be left bound to 0.0.0.0 after testing.

Where public connectivity is unnecessary, services should listen only on localhost or private network interfaces. Systems requiring remote access need authentication combined with perimeter controls, segmentation, and restrictions on permitted source networks.

Priority actions include:

• Upgrade Flowise to version 3.1.0 or later.
• Search code repositories and commit histories for API keys, n8n tokens, database passwords, webhook secrets, and other credentials.
• Rotate secrets that may have passed through exposed workflows or public repositories.
• Restrict unnecessary tool-calling, code execution, API access, and external integrations.
• Protect Attu consoles and scan separately for native Milvus and Qdrant interfaces.
• Monitor for unexpected inference requests, GPU utilization, workflow changes, token use, and activity in connected systems.
• Use product fingerprints in internet-scanning services to locate organizational assets visible from outside the network.

No compromise was confirmed by the study. Its practical finding is narrower but still consequential: tens of thousands of recognizable AI components are reachable from the internet, and many show no detectable access gate before the application itself.