1 Million Exposed AI Services: How Bad Is LLM Security?

What’s exposed

Researchers from Intruder scanned over 2 million hosts and found 1 million exposed AI services online. The findings are bad — most LLM deployments ship with insecure defaults, and many sit on the public internet with no authentication at all.

This isn’t a hypothetical risk. Real user data, internal company workflows, and production AI agents are accessible to anyone who knows where to look.

What the scan found

The investigation surfaced three categories of exposed services:

  • Open chatbot interfaces — instances of self-hosted UIs like OpenUI exposing user conversation histories. Some allow jailbreaking the underlying model entirely.
  • Agent management platforms — n8n and Flowise instances exposed without authentication. Attackers reaching these can pivot into integrated third-party systems (Slack, Gmail, internal APIs) the agents are wired into.
  • Unsecured Ollama APIs — over 31% of Ollama servers queried responded without authentication. An attacker can pull model state, modify workflows, or use the host to redirect traffic.

Why this happens

The pattern across these projects is “insecure by design”:

  • Fresh installs drop users straight into a high-privilege account with no auth required
  • Setup guides recommend docker run commands that bind services to 0.0.0.0 instead of 127.0.0.1
  • Hardcoded credentials embedded in docker-compose.yml examples, copy-pasted into production
  • Arbitrary code execution bugs found in popular AI projects within days of testing

The AI ecosystem is moving faster than its security model. Defaults built for “make it work” are getting deployed into “make it production”.

Defender checklist

If you run any LLM infrastructure, do these now:

  • Audit your perimeter for these ports: Ollama on 11434, n8n on 5678, Flowise on 3000, OpenWebUI on 8080
  • Verify bind addresses: services should bind to 127.0.0.1 (loopback) or an internal network — never 0.0.0.0 on a public host
  • Rotate any credentials from setup examples — assume anything in a public README is compromised
  • Check Shodan/Censys for your own org’s IP ranges using these queries: product:"Ollama", title:"n8n", http.title:"Flowise"
  • For Ollama specifically: set OLLAMA_HOST=127.0.0.1 and put a reverse proxy with auth in front if remote access is needed

Defender’s note: If you’re running self-hosted AI tools “for now while we evaluate them”, they’re production. Treat them that way from day one.

Leave a Comment

Your email address will not be published. Required fields are marked *