Open by Default — Why Self-Hosted AI Tools Ship Without Authentication and End Up Exposed

Section 01

Executive Summary

The tools teams use to build and run AI applications — local model servers, visual flow builders, experiment trackers, vector databases — share a design inheritance that is quietly dangerous. Almost all of them began as developer tools meant to run on one person's machine, where there is no one else to keep out. So they ship with no authentication by default, trusting that only the person at the keyboard can reach them. That assumption is reasonable on a laptop. It breaks the moment the tool is moved to a shared server and exposed to a network, which is exactly what happens as a prototype turns into something a team depends on.

The result is a large and growing population of AI infrastructure sitting on the public internet with no front door lock. This is not a theoretical concern. Security researchers have repeatedly found exposed instances of these tools numbering in the thousands, and attackers have industrialized the hunt for them. The failure is rarely a single exotic bug. It is the ordinary gap between how a tool is secured by its vendor and how it is actually deployed by the people who use it, the shared-responsibility gap where most real breaches live.

A review of the public vulnerability record shows the pattern is both widespread and under active exploitation. Ollama, a popular local model server, requires no authentication by default. Langflow, a visual AI app builder, shipped an unauthenticated remote-code-execution flaw that is on CISA's actively-exploited list and was used to recruit servers into a botnet. MLflow and the vector databases behind modern AI apps carry their own long trail of exposure and path-traversal flaws. The common thread is that the only reliable place to catch the problem is the deployment itself, not the vendor's release notes.

Ollama CVEs

Records in the National Vulnerability Database. Ollama requires no authentication by default.

Langflow on CISA KEV

Langflow entries on CISA's Known Exploited Vulnerabilities catalog — confirmed exploited in the wild.

MLflow CVEs

NVD records for MLflow, a widely self-hosted ML tool with a long history of exposure and path-traversal flaws.

Vector-DB CVEs

Across Pinecone, Qdrant, Milvus and Chroma. The data layer behind AI apps is accruing its own exposure surface.

Note on data and method: The vulnerability counts here come from my own review of the National Vulnerability Database (NVD) and CISA's Known Exploited Vulnerabilities (KEV) catalog, queried through ArgusX, a threat-intelligence platform I build that aggregates public security feeds into one searchable corpus. Every figure traces back to a public record; ArgusX is the lens, not the source.

Section 02

Why Self-Hosted AI Tools Ship Without a Lock

To understand the exposure, start with where these tools come from. A local model server like Ollama is built so a developer can run a large language model on their own machine with a single command. In that setting there is exactly one user, the API answers on localhost, and requiring a login would be friction with no security benefit. Nobody else can reach 127.0.0.1 anyway. So the tool ships open, and that default is correct for the environment it was designed for.

The problem is that these tools do not stay on the laptop. They get popular, a team wants to share one, and someone deploys it to a server, a cloud virtual machine, or a container. In the move, the one assumption the design rested on, that only a trusted local user can reach it, silently stops being true. The server now binds to a public address, the port is reachable from anywhere, and no one went back to add the authentication that was never there. The tool is doing exactly what it always did; the environment around it changed.

The shared-responsibility gap: A vendor secures the software it ships. The customer secures how they deploy and configure it. Exposed AI tools are a cousin of public cloud storage buckets and internet-facing databases with no password: the capability to lock the door exists, the deploying team just never used it. This gap is not incompetence so much as the predictable result of insecure defaults meeting fast-moving teams, and it is where the large majority of real-world compromises actually happen.

Two forces make the AI case sharper than the usual misconfiguration story. First, several of these tools execute code or load models by design, so reaching them unauthenticated is not just data exposure, it is a path to running code and replacing the weights an application trusts. Second, the write surface and the browser are both in play: an attacker can poison what the server serves, and even a server bound only to loopback can be reached through a user's own browser via permissive cross-origin settings or DNS rebinding. "It's only on localhost" is not the protection it sounds like.

check_circle As the Tool Assumes It Runs

Binding: Loopback only (127.0.0.1), reachable only from the machine it runs on

Users: One developer, on one trusted host

Auth: None, and that is fine, because no one else can route to it

Browser paths: Cross-origin and host-header checks still matter, but the blast radius is one machine

warning As It Actually Gets Deployed

Binding: Public or all-interfaces (0.0.0.0), reachable from the internet

Users: Anyone who finds the open port

Auth: Still none, because the default was never changed on the way to the server

Browser paths: Permissive CORS or missing rebinding protection let a visited web page drive the API too

Deployment model drawn from the default behavior documented for common self-hosted AI tools and from public exposure research.

Section 03

The Attack Chain — How an Exposed AI Server Gets Taken Over

Figure 1 — Exposed AI Infrastructure Attack Chain

Reconnaissance — Scanning for Open AI Endpoints

Attackers sweep the internet for the default ports and API signatures of popular AI tools using mass-scanning services. An exposed model server or flow builder answers an unauthenticated request and identifies itself, so building a target list of live, reachable instances is cheap and continuous. No prior knowledge of any specific victim is needed; the scan finds whoever left the door open.

Fingerprinting — Reading the Version

The same unauthenticated access that lists models or flows usually reveals the running version. That version maps directly to the published advisories that apply to it, so the attacker knows before sending a single exploit whether an instance is patched or vulnerable, and which flaw to use. An instance running a version behind the fix is selected; a patched one is skipped or revisited later.

Access — Walking Through the Unlocked Door

With no authentication in the way, the attacker uses the API as intended but against the owner. On a model server, that means reading the installed models and their configuration, and, where the write surface is also open, creating, pulling, and deleting models. On a flow builder like Langflow, an unauthenticated endpoint meant only to validate custom code actually executed it, turning access into code execution outright (CVE-2025-3248, fixed in 1.3.0).

Execution — Code, Weights, and Data

The payoff takes three forms. Remote code execution hands the attacker the host outright. Replacing the model weights an application serves is a silent supply-chain compromise: every later prompt is answered by weights the attacker controls, with the model name and tag unchanged. And the prompts and completions moving through the server, often carrying proprietary data and source code, are readable in transit when transport is unencrypted.

Abuse — Botnets, Mining, and Pivoting

A taken-over AI server is valuable beyond its data. Its GPU and inference capacity is hijacked for the attacker's own workloads or for cryptomining, and the host becomes a foothold to pivot deeper into the network. In the Langflow case, exploited servers were recruited into the Flodrix botnet, the clearest sign that this is automated, at-scale abuse of the installed base rather than targeted, hand-crafted intrusion.

Attack model based on public vulnerability reporting and exploitation research, including the Langflow CVE-2025-3248 campaign. MITRE ATT&CK: T1595.002 (Vulnerability Scanning), T1190 (Exploit Public-Facing Application), T1059 (Command and Scripting Interpreter), T1195.002 (Compromise Software Supply Chain), T1496 (Resource Hijacking).

Section 04

Key Findings

Authentication Is Off by Default Across the Category

The exposure is not a one-off bug in one product; it is a shared default. Ollama requires no authentication out of the box, and the same local-first design choice runs through flow builders, experiment trackers, and notebook servers. The secure option generally exists, a login, a reverse proxy, a loopback binding, but it is opt-in, and the path of least resistance deploys the tool exactly as it ships. A default that is safe on a laptop becomes a liability the instant the tool is put on a network.

CRITICAL

Exposed Instances Are Being Exploited Now, Not Hypothetically

Six Langflow entries sit on CISA's Known Exploited Vulnerabilities catalog, which means the U.S. government has confirmed active exploitation in the wild, not merely that a flaw exists. The flagship flaw, an unauthenticated remote-code-execution bug, was used to enlist exposed servers into the Flodrix botnet. Automated campaigns scanning for and compromising open AI infrastructure are a present-tense reality, and the population they feed on is the set of instances that were never patched or locked down.

CRITICAL

The Vendor Fix Does Not Reach the Installed Base

Langflow closed its remote-code-execution flaw in version 1.3.0, and that is the right fix. But a patch only protects the instances that apply it, and the exploited population is precisely the servers still running older versions or deployed with authentication disabled. "The vendor fixed it" and "organizations are still being compromised by it" are both true at once. The gap between a fix existing in a release and that fix reaching a running deployment is where the ongoing risk lives.

HIGH

The Write Surface and the Browser Are the Underrated Risks

Unauthenticated reads are bad; unauthenticated writes are worse. On a model server, an open write surface lets an attacker replace the weights an application serves, a model-supply-chain substitution that is invisible because the model name never changes. Separately, permissive cross-origin settings and missing DNS-rebinding protection let a web page the user merely visits drive even a loopback-bound instance through the user's own browser. A server that looks unexposed on the network can still be reachable from the web.

HIGH

Only the Deployment Can Answer Whether It Is Safe

Because the risk is the product of a vendor-side default and a customer-side deployment choice, neither party alone can certify safety. The vendor cannot know whether your instance is exposed, authenticated, and patched; a vulnerability feed cannot see your network bindings. The only reliable signal comes from inspecting the actual running deployment, is it reachable, does it require authentication, is it on a fixed version, which is why posture assessment of the instance itself, rather than trust in the release notes, is the control that closes the gap.

MEDIUM

Section 05

Recommendations

Defense operates at two levels: how an individual instance is deployed, and whether an organization can see its own exposure at all. Both are necessary. Neither is sufficient alone.

Keep AI Tools Off Public Interfaces by Default

Bind self-hosted AI tools to loopback unless there is a concrete reason to serve other hosts, and never expose their native ports directly to the internet. For a model server that means setting the host explicitly to 127.0.0.1. The single most common root cause in every exposure case is a tool reachable from a network it never needed to be on. Closing that removes the attack surface entirely, no matter what flaws the version carries.

Put Authentication in Front — Do Not Rely on the Default

Where a tool genuinely must serve a team or a network, place it behind a reverse proxy that enforces authentication, and forward only authenticated traffic to the tool on loopback. Assume the tool itself provides no access control, because by default most of these do not. Terminate client connections at the proxy, require a login or token there, and treat the tool's own port as internal-only.

Patch to a Fixed Version and Track What You Run

The exploited population is the unpatched one. Upgrade past known-exploited flaws, Langflow 1.3.0 or later for CVE-2025-3248 is the clear example, and maintain an inventory of which AI tools and versions run where. A fix you have not deployed protects no one. Version tracking is also what lets you react in hours, not weeks, the next time one of these tools lands on the exploited list.

Close the Browser-Borne Paths

Restrict cross-origin access to an explicit allowlist rather than leaving it open to every origin, and run versions that validate the host header so a loopback instance cannot be reached by DNS rebinding. These controls matter even for instances you believe are local-only, because the browser is a route into localhost that network firewalls do not cover. Treat "bound to loopback" as necessary but not sufficient.

For Security Teams: Scan the Deployment, Not the Vendor

Inventory your own AI infrastructure and assess each instance for the signals below, is it network-reachable, does it require authentication for reads and writes, is transport encrypted, is it on a fixed version. This is the one control that catches the gap the vendor cannot see and a CVE feed cannot measure. Find your exposed instances before an internet-wide scan does, because the scan is already running.

Detection Signals Summary

Signal	Indicator	Confidence	Notes
Unauthenticated reads	auth_required == false	High	Network-reachable instance answers with no credentials
Unauthenticated writes	write_auth == false	Critical	Model weights can be created, pulled, or replaced
Plaintext transport	tls == false	High	Prompts, completions, and tokens travel in the clear
Network-reachable bind	is_local == false	High	Served beyond loopback, reachable off-host
Open cross-origin	cors_any_origin == true	Med-High	Any visited web page can drive the API
Vulnerable version	version < patched	Critical	e.g. Langflow < 1.3.0 (CVE-2025-3248)
Running weights changed	running_digest ≠ installed	Medium	Model substituted under an unchanged name

Section 06

The Gap Between What Ships and What Is Deployed

Exposed AI infrastructure is not a hard problem to understand. The tools are built for a trusted local machine, they ship without authentication because that is correct for a laptop, and they end up on servers where that assumption no longer holds. The flaws that follow, unauthenticated reads and writes, plaintext transport, browser-reachable loopback instances, and in Langflow's case outright remote code execution, are the predictable consequence, not a surprise.

What makes the category urgent is that the exploitation is already industrialized. Scanning for open AI endpoints is cheap and continuous, versions are readable before a single exploit is sent, and compromised servers are folded into botnets. The installed base, not the current release, is the attack surface, and it grows every time a team stands up another instance in a hurry and moves on.

The reason this keeps happening is structural. A vendor can only secure the code it ships; it cannot reach into a customer's environment and decide how the tool is exposed. A vulnerability feed can tell you a flaw exists; it cannot tell you whether your particular instance is reachable, authenticated, or patched. The one place those two views meet is the running deployment, and until something looks at the deployment, the gap stays open regardless of how responsibly the vendor behaves.

The controls that close it are not exotic: bind to loopback, require authentication at a proxy, patch to a fixed version, restrict the browser-borne paths, and, for a security team, inventory and assess the instances directly. The checks that detect these conditions are straightforward to write. The analysis that explains why they matter is this one.

This analysis is based on publicly available information, including the National Vulnerability Database, CISA's Known Exploited Vulnerabilities catalog, vendor advisories and release notes for the tools discussed, and public exploitation reporting on CVE-2025-3248 and related campaigns. Vulnerability counts reflect my own review of the NVD and KEV corpora. A companion set of deployment-posture checks for self-hosted AI tools is in development as a contribution to the open-source security community. This analysis represents independent research produced as a contribution to that community.

Yana Ivanov

Security Analyst · Threat Intelligence · Detection Engineering

I'm a security researcher in Connecticut. Analysis is the part I love: tracing threat actor behavior, pulling apart supply chain attacks, and following evidence even when it lands on "unknown." When a question needs a tool that doesn't exist, I build it; most of the tools on this site started that way. Before security I spent 15 years designing enterprise software, which is why my tools assume a human will actually have to use them. I contribute detection rules to Sublime Security's open-source production ruleset. Security+ in progress. Everything here is independent work, shared as a contribution to the security community.

Portfolio