Running AI locally is supposed to give organizations more control. Models, prompts and documents stay on infrastructure they manage instead of being sent to a third-party cloud. But that advantage disappears quickly when the infrastructure itself is exposed to the public internet.
A new study from Mysterium VPN offers a useful snapshot of the problem. The researchers found 36,769 self-hosted AI endpoints across model servers, agent-building platforms and vector stores that were reachable and identifiable through a public internet scanning index.
“Only 2.02% return an HTTP authentication challenge; for the overwhelming majority, there’s no network-layer gate whatsoever.” reads Mysterium VPN’s report.
“Open WebUI: 18,529 reachable, 1 behind a gate: The most widely deployed local-LLM front-end has, as a population, no perimeter.”
That number needs to be read carefully. A service returning HTTP 200 isn’t automatically unauthenticated because a login page can also return 200. Mysterium therefore used HTTP 401 and 403 responses as evidence of an authentication gate and made a stronger claim only where the application fingerprint itself proved anonymous access.
“We counted the doors. We didn’t open them.” That distinction matters because the researchers didn’t connect to the exposed systems, retrieve data, run models, read credentials or exploit vulnerabilities. They queried Netlas, a third-party internet scanning index, and counted responses that matched specific fingerprints.
The largest number came from Open WebUI. The researchers identified 18,529 reachable instances, but only one returned an HTTP authentication challenge. vLLM accounted for another 4,880 endpoints, with just three showing an authentication challenge, while LocalAI had 150 and llama.cpp 69, with neither showing a challenge.
Ollama produced a particularly important finding because the researchers could verify anonymous access from the service response itself. An exposed Ollama server returns the text “Ollama is running” from its root endpoint without requiring credentials, and 6,935 hosts returned that fingerprint. Of those, 6,046 returned an explicit HTTP 200 response.
This isn’t just about seeing a chatbot from the internet. An exposed Ollama API can reveal the models installed on the machine and can be used to generate text using the owner’s hardware. That creates a straightforward resource-abuse problem: someone else gets the GPU time and the owner gets the electricity bill.
The security community calls this LLMjacking, but the underlying problem is familiar. The AI label doesn’t make an exposed API magically safer.
There is also evidence that this isn’t a small or isolated deployment mistake. A separate SentinelOne and Censys study published in January identified around 175,000 publicly exposed Ollama hosts across 130 countries. Almost half of those systems supported tool-calling capabilities that could execute code, access APIs or interact with external systems.
Mysterium’s own number is much smaller because it comes from a different scanning source and a stricter fingerprint. The researchers explicitly describe their 36,769 endpoints as a lower bound rather than a measurement of the entire internet. They also found 22,024 responses on Ollama’s default port 11434, but excluded those from the main total because a port number alone doesn’t prove which service is running there.
The more interesting security issue may sit one layer above the model itself.
Mysterium found 5,223 exposed agent builders and workflow platforms, including Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow and Open WebUI Pipelines. These systems deserve more attention because they don’t simply host an AI model. They often connect that model to the rest of the company’s infrastructure.
An automation workflow can contain an OpenAI API key, database credentials, Slack tokens, webhook secrets, CRM passwords and other information needed to make the workflow work. They aren’t broken. They’re doing what they were designed to do. The problem starts when someone places that functionality directly on the internet without another security layer in front of it.
Flowise is a good example. Mysterium identified 1,341 reachable Flowise instances and found zero HTTP authentication challenges among them. The same report points to CVE-2026-40933, a critical Flowise vulnerability that can allow an authenticated attacker to execute arbitrary commands through the MCP adapter. Flowise fixed the issue in version 3.1.0.
That combination matters. A reachable application isn’t necessarily vulnerable, and a vulnerability doesn’t automatically mean an internet-facing installation can be compromised. But putting a system that stores credentials on the public internet increases the number of ways an attacker can eventually reach those credentials.
n8n illustrates another part of the problem: attackers don’t always need a vulnerability.
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 the 896 instances that were reachable during testing, 321 accepted at least one leaked token.
Those credentials could provide access to workflows and connected systems without exploiting a software flaw. That’s an important lesson for AI security because many organizations now use automation platforms to connect databases, cloud services, source-code repositories, customer systems and AI services.
The risk doesn’t stop at the workflow layer. Vector databases can contain the actual information that an AI system uses to answer questions.
Mysterium identified 920 vector-store endpoints, almost all of them exposed Attu consoles for Milvus. But the researchers are clear that this number tells us very little about the real exposure. Qdrant’s native port and Milvus’s native database port weren’t scanned by the source, so a database could be publicly reachable without appearing in the census.
That makes the vector-store figure a floor, not a ceiling. A model server exposes computing capability, an agent builder can expose credentials, and a vector store can expose the information that an organization has loaded into its AI system: internal documents, support tickets, customer records or private knowledge bases.
“We are reporting a floor of 920 for the one class where the true number is likely highest. Nobody should read this study as evidence that self-hosted vector databases are well protected.” continues the report. “We simply couldn’t see them.”
That’s one of the most important qualifications in the research. The absence of evidence here isn’t evidence that these systems are safe.
The same caution applies to geography. Mysterium wanted to publish a country breakdown, but rate limits prevented reliable results for several major countries. Rather than publish a misleading ranking, the researchers dropped it. The one figure they could support was that 4,136 of the 22,024 responses observed on port 11434, or 18.8%, came from the United States.
The study also deliberately avoided turning exposure into compromise. The researchers didn’t contact the hosts, retrieve documents, inspect prompts or chat logs, read credentials, run inference, exploit vulnerabilities or publish IP addresses and hostnames. That’s important because the research measures exposure, not confirmed compromise.
The underlying problem, however, is difficult to dismiss.
Over the past two years, organizations and individual developers have moved more AI infrastructure away from managed cloud services and onto their own machines. That can improve privacy and control, but it also transfers much of the security responsibility to whoever deploys the system.
A local AI stack should therefore be treated like any other internet-facing service. If the model doesn’t need to be reachable from the internet, bind it to localhost or a private network. If remote access is necessary, put authentication and network controls in front of it, rather than relying entirely on the application’s own login system.
The same logic applies to agent builders. If an n8n or Flowise installation holds API keys and credentials that can reach production systems, it deserves the same level of protection you’d give a password manager. Calling it an “AI tool” doesn’t reduce the value of what it stores.
There is also a basic operational question that many organizations should answer now: what AI infrastructure is already exposed?
Mysterium’s fingerprints can be used with internet-scanning services to check for exposed deployments. That makes the research useful not because it proves that 36,769 systems are compromised, but because it gives defenders a way to look for their own systems before someone else does.
And that may be the uncomfortable part of the findings. The AI security problem isn’t always a sophisticated model attack or a novel prompt-injection technique. Sometimes it’s a developer binding a service to 0.0.0.0
, putting it on a cloud server and forgetting that the internet can see it.
“None of this is a vulnerability report, and it would be unfair to file it as one. Ollama, Open WebUI, Flowise, and n8n aren’t broken.” concludes the report. “They’re doing what they were designed to do: run on a machine and serve a local user. The failure is in deployment — thousands of people binding to 0.0.0.0 on a cloud box, in a hurry, and never putting anything in front of it. “
The AI is new. Leaving the front door open isn’t.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, AI)