Mysterium Exposed AI Endpoints, and Self-Hosting Lost Its Security Alibi

Mysterium exposed AI endpoints at a scale that turns a configuration mistake into an industry warning. Its researchers identified 36,769 reachable systems, while only 741 returned an HTTP authentication challenge.

The September 10 study covered model servers, chat interfaces, agent builders, and vector-store consoles. These components form the operational layer between an AI model and the people, documents, credentials, and applications around it.

That creates an uncomfortable conflict for self-hosted AI. Companies often run models locally to retain control over prompts and sensitive data. Yet many deployments appear reachable without a network-level gate, shifting trust toward application security, patching, and correct configuration.

The count does not prove that all 36,769 systems exposed private information. Some applications could still require users to sign in after loading. However, the findings show that thousands of AI services announce themselves directly to internet scanners.

That distinction matters. A visible login page is still an exposed application that must survive new vulnerabilities, stolen passwords, weak defaults, and automated probing. A service behind a private network or authenticated gateway presents a smaller target.

The comparison is therefore not simply local AI versus hosted AI. It is control in principle versus control in deployment. Mysterium’s results suggest that organizations are choosing self-hosting without consistently operating the security boundary that makes self-hosting valuable.

Mysterium Exposed AI Endpoints Across the Working AI Stack

The central finding is not one vulnerable product. It is a recognizable AI stack that can be mapped from the public internet.

Mysterium said its researchers used a third-party scanning index instead of directly probing the identified machines. The original census searched for service fingerprints, including page titles, response text, and ports associated with common AI software.

The final dataset contained 36,769 self-identifying endpoints. Model-serving products accounted for most of that population, led by 18,529 Open WebUI instances. Open WebUI provides a browser-based interface for interacting with locally hosted language models.

Only one of those Open WebUI endpoints returned an HTTP authentication challenge during the study. That does not establish that the remaining applications allowed unrestricted account access. It does establish that almost none had a detectable HTTP gate placed in front of the application.

Ollama, a service for downloading and running models on local hardware, represented another 6,935 confirmed endpoints. Each anonymously returned the product’s root response, according to Mysterium. Of that group, 729 returned an authentication challenge.

The researchers also identified 4,880 vLLM endpoints, with three returning a challenge. vLLM is an inference server, meaning it accepts requests and runs them through a language model to produce responses.

Smaller groups included 150 LocalAI endpoints, 69 llama.cpp servers, and 63 Xinference deployments. These products serve different audiences, but they share an operational purpose. They make models accessible to applications or users.

The dataset extended beyond inference. Mysterium counted 5,223 endpoints associated with agent builders and workflow tools, including Flowise, RAGFlow, Dify, ComfyUI, n8n, Langflow, and Open WebUI Pipelines.

That category carries a different risk profile. An inference server processes prompts, but an agent builder often connects models to databases, messaging systems, cloud services, and internal applications. It can store tokens or invoke tools with real permissions.

Flowise accounted for 1,341 reachable endpoints, none of which returned an authentication challenge. The study also counted 891 RAGFlow deployments, 792 Dify endpoints, 788 ComfyUI endpoints, and 675 n8n instances.

Vector-store visibility was much lower. Researchers found 914 Milvus Attu consoles and six Weaviate endpoints. A vector store holds numerical representations of content so an AI application can retrieve relevant documents during a conversation.

Those numbers should not be read as evidence that vector databases are rarely exposed. Mysterium said its source did not scan the native ports of two major products. The census mainly captured visible web consoles, leaving the most data-sensitive category poorly measured.

The report also found 22,024 additional responses on Ollama’s default port. Researchers excluded them from the confirmed total because a port response alone offered weaker evidence than a recognizable product banner.

That conservative exclusion strengthens the main conclusion. The 36,769 figure is a confirmed floor within one scanning index, not a complete inventory of public AI infrastructure.

Why Self-Hosted AI Security Breaks at the Perimeter

Self-hosting protects data only when the organization also controls who can reach the host.

The case for local models usually starts with data custody. Prompts, uploaded documents, retrieved passages, and generated answers can remain on equipment controlled by the organization. That arrangement can reduce dependence on an external model provider.

However, location alone does not create confidentiality. A model running on company hardware can still be public if its service listens on an internet-facing address. An internal deployment can become external through a firewall rule, cloud security group, container setting, or hastily configured tunnel.

Many local AI products listen only on the loopback address by default. Loopback limits connections to software running on the same machine. Operators sometimes change that address to 0.0.0.0, which allows the service to accept connections through every available network interface.

That change is useful when a developer needs access from another device. It becomes dangerous when the surrounding network also permits inbound internet traffic.

A reverse proxy can provide an authentication layer before requests reach the AI application. A virtual private network can keep the service outside the public address space. An IP allowlist can restrict access to approved networks.

Mysterium found little evidence of those HTTP-level protections. Across the full census, only 2.02 percent of endpoints returned an authentication challenge. Five product queries were incomplete because of source rate limits, so the researchers did not assign challenge counts to those groups.

The narrow interpretation is important. An HTTP challenge is not the only possible security control. An application can load publicly and still enforce its own login, session, or authorization rules.

Yet relying on application authentication changes the threat model. The application becomes continuously reachable by scanners and attackers. Every missed patch, authorization error, exposed administrative route, and default credential becomes more consequential.

Recent vulnerability records show why that concern is concrete. Tenable’s 2026 security advisories listed high-severity issues affecting Open WebUI and several Flowise components.

The Flowise advisories included path traversal, graph-query injection, missing authentication on NVIDIA NIM endpoints, and personal-information disclosure. Separate advisories covered credential exposure, authorization failures, and arbitrary file writes across other AI tools.

Those records do not mean every internet-visible deployment is vulnerable. Versions, configurations, and compensating controls differ. They demonstrate that the application layer cannot serve as a permanent substitute for network isolation.

Patch timing creates another problem. A developer can launch a useful proof of concept in minutes, then leave it operating for months. The service might never enter the asset inventory used by security and infrastructure teams.

That lifecycle produces shadow AI, systems adopted or built without normal organizational oversight. The project remains visible to its creator but invisible to the teams responsible for access reviews, updates, logs, and incident response.

The result is a security boundary built from assumptions. The data scientist assumes the cloud firewall blocks traffic. The infrastructure team assumes the application requires authentication. The application owner assumes the deployment is temporary.

An internet scanner tests those assumptions without needing organizational context. If the product responds, identifies itself, and presents an application surface, it has already crossed one boundary that self-hosting was supposed to preserve.

Agent Builders Turn Exposure Into Supply Chain Risk

The most serious exposed AI endpoints do more than answer questions, because they can act through credentials and connected systems.

An AI supply chain includes the model, software packages, serving infrastructure, retrieval databases, plugins, tools, and external services used to produce an outcome. A weakness in any connected component can influence the system or expand an attacker’s access.

Traditional software supply chains already carry inherited risk. Applications depend on packages maintained by outside developers, container images built elsewhere, and automated workflows holding deployment credentials.

AI applications add prompts, model files, retrieval content, agent instructions, and tool definitions to that chain. Some of these artifacts look like data, although they can alter what an agent does.

Fortinet described agent skills as a new dependency layer for coding assistants. Its skills analysis noted that a skill can use natural-language instructions to tell an agent to access files, run shell commands, or transmit information.

That behavior does not always require a conventional software flaw. A malicious instruction can become operational when an agent trusts it and has permission to use the requested tool.

An internet-exposed workflow builder combines these risks. It can reveal which integrations an organization uses, accept untrusted input, or expose routes that interact with stored credentials. A compromised workflow could then reach systems far beyond the original AI server.

Consider a retrieval assistant used by an engineering team. The application might connect to a source-code repository, a documentation store, an issue tracker, and a model endpoint. Its vector database could contain fragments of internal documents.

If the public interface has an authorization flaw, the attacker’s prize is not limited to free model inference. The attacker could access retrieved content, workflow definitions, connection metadata, or tokens, depending on the product and configuration.

A customer-support agent presents a similar path. It might connect to email, order records, messaging tools, and a customer database. Even a narrowly scoped credential becomes valuable when the workflow can combine information across services.

That is why the 5,223 agent-builder endpoints deserve separate attention from the model servers. The smaller population can carry a larger operational blast radius.

Tenable’s February cloud risk report provides enterprise context. Its telemetry showed that 70 percent of analyzed organizations had integrated at least one third-party AI or Model Context Protocol package.

Model Context Protocol, or MCP, is a standard that lets AI applications connect to tools and data sources. Its usefulness comes from granting models structured access to external capabilities.

Tenable also reported that 18 percent of organizations had given AI services administrative permissions that were rarely audited. The company found that non-human identities, including agents and service accounts, presented higher measured risk than human users.

Those findings come from Tenable’s customer and cloud telemetry, not Mysterium’s internet census. The datasets should not be merged into one prevalence estimate. Together, they show two sides of the same operational problem.

Mysterium measured reachable services. Tenable measured permissions, third-party packages, and identity conditions inside enterprise environments. Public exposure becomes more consequential when the reachable service also controls a privileged non-human identity.

The pressure falls on both developers and security teams. Developers need fast access to models and integrations. Security teams need an inventory, clear ownership, limited privileges, and evidence that every public service has a deliberate reason to exist.

Neither goal can be achieved through model policy alone. A model refusing a harmful prompt does not repair a public administrative console. Provider guardrails do not rotate a leaked token or remove an abandoned container.

Organizations that use AI to work with internal knowledge also need to classify what enters retrieval systems. A searchable knowledge base can improve access to technical material, but its storage and connectors inherit the sensitivity of that material.

The security question therefore moves upstream. Before an agent receives a prompt, someone must decide which data it can retrieve, which tools it can invoke, and which network can reach it.

What the 36,769 Figure Does Not Prove

The census demonstrates public reachability, but it does not establish 36,769 successful compromises or data leaks.

Internet measurement can produce an arresting number without answering every security question. Product fingerprints identify services, while an HTTP response reveals something about their perimeter. Neither automatically reveals the application’s internal authorization state.

Some endpoints in the dataset likely displayed a login page. Others might have restricted important functions after loading the interface. Some could have been research systems, honeypots, intentionally public demonstrations, or empty test installations.

Mysterium acknowledged this boundary. The report did not claim that every visible application allowed anonymous access to private features. It described the lack of a network or HTTP gate as the common exposure.

This limitation prevents a direct calculation of breached records, vulnerable organizations, or affected users. The researchers did not publish a list of target owners, and doing so could create additional risk.

The authentication measurement also varies by product. Only 12 of the 17 product categories had resolved challenge counts. A dash in the dataset indicated an incomplete query, not confirmed absence of authentication.

Geographic analysis was limited as well. Mysterium reported country attribution for only a subset of Ollama responses on its default port. Any broad claim about which countries or industries are most exposed would go beyond the evidence.

The endpoint count can also include multiple services operated by one organization. Conversely, one endpoint can sit in front of a larger shared environment. The number of reachable addresses is not the number of affected companies.

Scanner coverage presents another uncertainty. A different index, query schedule, or fingerprint can return a different population. Services go online and offline, change banners, move behind proxies, or receive patches.

These limitations do not erase the finding. They change the conclusion from “36,769 compromised systems” to something more precise: thousands of recognizable AI services were reachable through one public scanning index.

That condition is valuable to attackers before exploitation begins. Product identification helps automate vulnerability matching. A scanner can search for a known interface, estimate its version, and test applicable routes at scale.

The difference between exposure and compromise resembles an unlocked street-facing door. Seeing the door does not prove that someone entered. It does show that the property depends more heavily on every remaining interior control.

The report’s 2.02 percent figure also requires care. Basic HTTP authentication is not inherently better than modern application authentication in every architecture. A poorly managed proxy can introduce its own weaknesses.

The stronger principle is defense in depth. A sensitive AI service should not depend on one application login when private networking, authenticated gateways, identity-aware proxies, and limited inbound rules are available.

There is also a commercial incentive behind some of the broader commentary around AI exposure. Security vendors benefit when organizations purchase discovery, scanning, identity, and monitoring products. Their recommendations should be evaluated against technical evidence.

Mysterium itself is a VPN company, which makes network privacy relevant to its business. That does not invalidate its dataset. It makes transparent methods, reproducible fingerprints, and independent confirmation more important.

The study published its fingerprints and explained excluded results, rate-limit gaps, and undercounted categories. Those choices make the central measurement easier to test than a claim based only on private telemetry.

The next useful research step is controlled validation. Independent teams should repeat the queries, sample endpoint behavior without accessing sensitive content, and track how the population changes after disclosure.

A falling count would suggest operators or software maintainers responded. A stable count would indicate that insecure deployment is structural rather than temporary.

The Real Tradeoff Is Deployment Speed Versus Verifiable Control

The Mysterium exposed AI endpoints study challenges the idea that self-hosting automatically delivers privacy.

Hosted AI concentrates trust in a provider. Customers rely on contracts, service isolation, retention controls, access policies, and the provider’s security program.

Self-hosting redistributes that trust. The organization controls the hardware and deployment, but it also inherits patching, identity management, network design, logging, backups, and incident response.

That can be the right choice for regulated information or specialized workloads. It is not the easier choice by default. The local server must be operated as sensitive infrastructure, not as a desktop experiment that happened to become shared.

Speed creates the core tension. AI frameworks are designed to reduce the distance between an idea and a working application. A researcher can launch an interface, attach a model, connect documents, and share the result quickly.

Every convenience can conceal an operational decision. Exposing a port makes collaboration easier. Storing a token in a workflow makes integration faster. Granting broad permissions avoids repeated authorization errors.

Those decisions accumulate into an environment that works before anyone has defined its security boundary. The application becomes useful, attracts users, and moves closer to production while retaining its experimental controls.

Traditional security processes can also contribute to the gap. If obtaining an approved environment takes weeks, employees will build around the process. Blocking every AI service without providing a usable path encourages unmanaged alternatives.

Organizations need a deployment route that is fast enough to compete with shadow infrastructure. That route should provide private networking, managed identity, secret storage, logging, patch ownership, and expiration dates by default.

Short-lived experiments deserve expiration dates because temporary systems rarely remove themselves. A cloud instance created for a demonstration can remain online after its owner changes roles or forgets the project.

Inventory must include the whole operational chain. Finding a model server without its vector store, workflow engine, container host, and service accounts leaves defenders with a fragmented picture.

Identity deserves equal attention. An agent should receive the narrowest permissions required for its task. Administrative credentials should not become the standard answer when an integration fails.

Credentials stored in public or previously exposed workflows should be rotated. Removing internet access closes one path, but it does not invalidate a token that an attacker might already possess.

Logs must cover actions, not only conversations. Teams need to know which tool an agent invoked, which identity it used, what resource it reached, and whether the action matched an approved workflow.

This is especially important when agent instructions come from third parties. An imported template, plugin, or skill can alter behavior without resembling executable code. Reviews must examine both conventional packages and natural-language control files.

Software maintainers also face pressure. Secure defaults should make accidental exposure harder. Products can warn when services bind to public interfaces, require first-run credentials, and separate administrative routes from user-facing endpoints.

Documentation matters because tutorials often become production architecture. A quick-start guide that exposes a service without explaining the network consequences can propagate the same mistake across thousands of installations.

Cloud and model providers remain part of the comparison. Managed platforms can reduce configuration work, but they introduce provider concentration and account-permission risks. The answer is not that one hosting model always wins.

The defensible choice is the one whose controls can be verified. An organization should know where the model runs, who can reach it, what data it processes, which identities it uses, and how quickly access can be revoked.

Three Signals Will Show Whether the Exposure Shrinks

The next test is whether maintainers and operators turn a widely reported census into measurable remediation.

The first signal is a repeat internet scan using the same fingerprints. The most revealing measures will be the confirmed endpoint total and the share protected by network-level authentication.

A lower endpoint count would suggest that operators removed unnecessary public access. A higher authentication rate would show that services remained useful while gaining a perimeter.

Neither change alone is sufficient. An endpoint can disappear from a fingerprint because its banner changed, while remaining reachable. Researchers should therefore document query changes and preserve comparable measurements.

The second signal is action from major maintainers. Open WebUI deserves particular attention because it represented 18,529 endpoints, roughly half of Mysterium’s confirmed population.

Warnings for public binding, mandatory initial credentials, safer deployment templates, and clearer reverse-proxy guidance would strengthen the report’s broader case. Silence or cosmetic banner changes would leave the operational problem largely intact.

Agent builders should receive even closer scrutiny. Flowise, RAGFlow, Dify, n8n, Langflow, and similar tools need secure defaults that recognize their access to secrets and external systems.

The third signal is vulnerability and incident evidence. New advisories involving authorization, credential disclosure, remote execution, or agent-tool access would show how public exposure can become an attack path.

Confirmed exploitation would strengthen the urgency, but defenders should not wait for it. The absence of disclosed incidents does not establish safety when asset owners might lack logs or visibility.

Organizations can act before those signals arrive. They should inventory AI services, test which interfaces are publicly reachable, and identify the people responsible for every deployment.

Anything that does not require public access should bind to a private interface. Services that must remain reachable should sit behind authenticated gateways with limited identities and current patches.

Agent builders need additional treatment as secrets infrastructure. Teams should review stored integrations, rotate exposed credentials, inspect imported workflows, and record agent actions against connected systems.

The Mysterium exposed AI endpoints count will eventually become outdated. That is expected. The important question is whether the next count reflects better controls or merely a larger collection of overlooked services.

For developers, enterprise buyers, and AI users, the practical test is simple: can the organization show who can reach each system and what that system can do? If the answer depends on assumptions, the deployment is not providing the control that self-hosting promised.