One million exposed AI services: what the Intruder scan actually found

What is this?

On May 5, 2026, The Hacker News published We Scanned 1 Million Exposed AI Services. Here’s How Bad the Security Actually Is, a contributed report from the Intruder security team. Using certificate transparency logs as the seed, the team enumerated just over 2 million hosts, identified 1 million exposed AI services, and triaged a subset of the most common stacks in a lab environment. The conclusion, in their words: “the AI infrastructure we scanned was more vulnerable, exposed, and misconfigured than any other software we’ve ever investigated.”

The report is the line item we are covering here — not because it discloses a new vulnerability class, but because it quantifies, with a reproducible methodology, a problem most LLM security writing treats as anecdotal. Trend Micro’s Fault Lines in the AI Ecosystem report and its press release on exposed AI servers corroborate the same pattern from a different vantage point, and Cybernews had previously surfaced more than 175,000 exposed AI systems including unauthenticated Ollama instances. The signal is consistent across three independent measurements.

How it works

There is no novel attack in the Intruder write-up. The methodology is plain reconnaissance applied at scale, and the failure mode is design-level. The categories of exposure reported are stable enough to summarise as a workflow.

Stage                          What an unauthenticated scanner sees
-----------------------------  -----------------------------------------------
1. Discovery                   Certificate-transparency logs → ~2M candidate
                               hosts running AI-adjacent services
2. Fingerprinting              Open ports answer with project banners
                               (Open WebUI, Flowise, n8n, Ollama, etc.)
3. Auth probe                  Hitting "/" or model endpoints with no header
                               → many return content, not 401/403
4. Capability probe            Sending a benign prompt ("Hello") to Ollama
                               APIs that advertise a loaded model
5. Configuration probe         Reading docker-compose, env files,
                               documented default credentials
6. Tool inventory              For agent platforms (Flowise, n8n): listing
                               nodes, credentials, prompts, attached tools

Three findings carry most of the impact.

Chatbots with no auth in front. Instances based on Open WebUI exposed users’ full LLM conversation history to anyone who landed on the host. Generic chat fronts wrapping multimodal frontier models — Claude, GPT, Gemini, DeepSeek, Moonshot — were left fully open; the Intruder team counted 518 servers wrapping well-known frontier models out of those they were able to fingerprint. Open chatbots become a free, unattributable jailbreak surface for whoever finds them, with the host’s API keys paying the bill.

Agent management platforms reachable from the internet. Exposed Flowise and n8n consoles revealed entire chatflows: the business logic, the prompts, the credential list, and the tools wired into them. The credentials were not always readable in clear, but the tools they unlocked were directly callable. Intruder identified more than 90 such exposed instances across government, marketing and finance — environments where the connected systems are the real prize.

Ollama APIs answering “Hello”. The team queried 5,200+ exposed Ollama servers that advertised a loaded model and 31% answered a single-token prompt, confirming the absence of authentication and an active inference path. Ollama itself does not persist conversations, but a third of those endpoints were ready to act as free GPU-backed inference for any caller, including ones routing to frontier-model proxies.

The underlying defects, when reduced to a list, are familiar from twenty years of cloud-config audits:

Insecure-by-default pattern             Concrete instance
--------------------------------------- -------------------------------------
No authentication on fresh install      Open WebUI, Ollama, Flowise (depending
                                        on deploy mode), n8n self-hosted
First user lands as admin               Many self-hosted LLM front-ends
Hardcoded / static credentials in       docker-compose examples copied to
example configs                         production verbatim
Application running as root             Several reviewed projects
Sandbox weak or absent for code tools   Code interpreter / file-write nodes in
                                        agent platforms with host-level reach

Why it matters

The numbers are useful precisely because the bug classes are not. None of this requires a model jailbreak, an indirect prompt injection, or a frontier-tier exploit. It is the LLM hosting layer reproducing every misconfiguration template that mature cloud-native tooling spent a decade trying to retire.

Three implications matter for defenders.

First, the attack surface is mostly invisible to traditional inventory. Most of these deployments are stood up by application teams using Docker on a VPS or in a sandbox account, behind a TLS certificate that is the only durable trace. Certificate transparency was sufficient for Intruder to find them; it is sufficient for an attacker to find yours.

Second, the chatbot is a credential-handling system. An open Open WebUI instance backed by a paid API key is, functionally, an unattributable account belonging to the next person who jailbreaks it. The relevant analogy is not “leaked chat log” — it is “leaked OAuth token with a generous quota”. Lasso Security’s Amazon chatbot study documents the same abuse pattern against a hosted bot; the Intruder scan finds the self-hosted equivalent at scale.

Third, the blast radius for agent platforms is the connected stack. An exposed Flowise console with an Airtable, Slack, Notion or internal database tool wired in is reachable by an unauthenticated visitor, and recent disclosures — Flowise’s Airtable Agent CVE-2026-41265 and the broader Prompts as shells class — show that even when the credentials themselves are masked, the tool registry is enough to obtain code execution or data exfiltration.

Defenses

The fix list is operational, not algorithmic. None of it requires new tooling beyond what mature security teams already operate.

1. Inventory externally reachable AI endpoints with certificate-transparency. Pull your own organisation’s CT logs, filter for hosts that look like AI infrastructure (Open WebUI, Flowise, n8n, Ollama, vLLM, LM Studio, Text Generation WebUI, LiteLLM and similar), and confirm each one is intentional, authenticated and rate-limited.

2. Treat the default install as the threat model. Before exposing any AI front-end, verify that authentication is enabled, that the first account is not auto-admin, that credentials are generated at install time rather than copied from a docker-compose example, and that the container is not running as root. The Intruder report is explicit that these are the recurring failures — not bug classes, but defaults.

3. Put a credential boundary between the chatbot and the API key. A self-hosted bot must hold its own per-user identity, with quotas and audit, before it is allowed to consume an upstream API key. If your model wrapper exposes the underlying key in a config endpoint or environment-variable dump, treat the wrapper as untrusted and put a proxy in front.

4. Air-gap the agent control plane. Flowise, n8n, Dify, LangFlow and equivalent visual builders are management consoles. They belong behind SSO and on an internal network, never on a public TLS certificate. If a developer must work remotely, route through a VPN or zero-trust gateway, not through 0.0.0.0.

5. Apply the AI-asset side of the agents-rule-of-two. For each exposed agent, decide before deployment which two of {untrusted input, sensitive data, external action} the session may hold, and enforce that cut at the network layer in addition to the prompt layer.

6. Log inference and tool calls as security events, not metrics. Conversational logs from open chatbots and tool-call traces from agent platforms are the primary indicator of abuse. They belong in the same pipeline as authentication failures, not in a separate observability silo.

7. Re-baseline your external attack surface monitoring. If your ASM stack does not fingerprint Open WebUI, Flowise, n8n, Ollama and the common LiteLLM proxies, add them. The Intruder scan demonstrates that these stacks are now a dominant share of the new exposed surface, not a marginal one.

Status

Stack	Exposure pattern documented in the May 2026 scan	First line of defence
Open WebUI	Full chat history readable; multimodal models freely usable	Enable auth, put behind SSO, rotate upstream keys
Flowise	Console reachable; chatflows, prompts and tool inventory readable	Move console to private network, enable auth, audit nodes
n8n	Workflow editor reachable without auth	Enable basic auth or SSO, restrict to private network
Ollama	31% of probed servers answered an unauthenticated prompt	Bind to localhost, front with authenticating reverse proxy
Self-hosted chat fronts	API keys for Claude / GPT / Gemini exposed in plaintext config	Vault upstream credentials, scope per session

The Intruder report is dated May 5, 2026. The Trend Micro write-up was reported by PR Newswire on July 22, 2025, and the Cybernews tracking of exposed Ollama infrastructure predates both. Three independent measurements, one consistent picture: the LLM hosting layer is shipping with the defaults turned the wrong way. The defensive answer is not new — it is the work cloud platforms did between 2010 and 2020, repeated for a stack that has not yet had to learn the lesson.