Open WebUI on Public Cloud: Auth Posture Survey

NuClide Research · 2026-05-03

Summary

Reused the 20,581 port-3000 hits from the prior Flowise sweep and re-fingerprinted them for Open WebUI (the popular Ollama / OpenAI-compatible chat frontend) via GET /api/version body match ({"version":"0.x.x"}) plus /api/config for auth-state + branding. 112 confirmed Open WebUI instances across DO/Hetzner/Vultr.

DCWF KSAT coverage

Auto-derived from DCWF AI work-role rule files (ksat-tag).

• 672 (AI Test & Evaluation Specialist): K7003, K7004, K7044, S7068, S7070, S7075, T5904
• 733 (AI Risk & Ethics Specialist): K7051, T5868, T5882, T5893, T5904
• overlap (Common AI KSATs (all 5 roles)): K108, K1158, K1159, K22, K6311, K6935, K7003, K942

In contrast to the vector-DB and inference-server tier, Open WebUI ships auth-on by default and operators have largely left it that way: 111 of 112 instances enforce authentication. This matches the earlier finding for Flowise (43 instances, 0% unauth) and n8n (1006 instances, 0% unauth), orchestration / chat-UI tier is closed-by-default.

The new finding shape is operator-policy misconfiguration rather than auth-disabled: 14 of 112 instances have enable_signup: true at the application layer. Authentication is required, but anyone can register an account from the public internet and use the operator’s Ollama/OpenAI-compatible backend. Five of those are branded deploys with operator-attributable names (“Aera IA”, “TopicalBase AiChat”, “Lexa”, “Tuuci AI”, “CloudU3 AI Platform”), meaning the operator ID is visible in the /api/config response.

A side benefit of the survey: branded deployments reveal previously-unmapped commercial AI-chat products that can be cross-referenced for further investigation.

Methodology

Reused IPs from prior Flowise port-3000 masscan: 20,581 hosts

openwebui-probe.py (200-thread fingerprint)
  GET /api/version → {"version":"x.y.z"} (Open WebUI shape)
  GET /api/config  → features (auth, signup, ldap, api_keys), name, default_models
  GET /api/models  → model list (gated in newer versions)
  → 201 raw matches → 112 confirmed Open WebUI (via /api/config name + features shape)

The 89 raw matches that weren’t Open WebUI are other apps with /api/version that happen to return JSON with a “version” key, generic Node.js dashboards, custom apps using arbitrary version strings (Unix timestamps, CalVer-style numbers, etc.). Distinguishing was via /api/config returning the Open WebUI features shape (auth, enable_signup, enable_login_form, enable_websocket, etc.).

Findings Summary

Version distribution (top 10)

The bulk of the surveyed population is on 0.7.x – 0.9.x, with a long tail going back to 0.3.x. Open WebUI’s release cadence is rapid; a meaningful fraction of operators are 6+ minor versions behind, exposing them to whatever security fixes have shipped in the interim.

Class A: Public-Signup Instances (HIGH: anyone-can-register)

enable_signup: true in /api/config means the chat UI’s login page exposes a “Sign up” button that creates a new user account from a public form. Combined with enable_login_form: true (also set on these), the registration flow is fully open to the internet. New accounts default to pending or user role depending on the version + operator config.

If the operator is paying for backend Ollama GPU compute or for OpenAI/Anthropic API quota that the chat UI proxies, every new external account drains that compute/quota.

Risk class: quota exhaustion / unauthorized usage. An attacker registers, uses the chat UI to query the operator’s models freely. For operator-attributed deploys (Aera IA, TopicalBase, Tuuci AI, CloudU3) the operator’s brand is also visible to the registering user, likely they think their tooling is more closed than it actually is.

Class B: Branded Deployments (HIGH informational: operator attribution)

Six instances expose a custom brand name in /api/config.name, identifying the operator’s commercial AI product even where the underlying tech is generic Open WebUI:

The custom-named deploys with non-Open-WebUI version numbers (Lexa v3.0, Chatty AI v4.0.1, InsightERA CorpGPT v1.2.1) are likely forks of Open WebUI that have rebased the version string. Whoever maintains those forks may have re-pointed the security defaults too, worth tracking as separate operator entities.

Cross-Survey Pattern (updated)

The pattern crystallizes: the data and inference tiers ship unauthenticated and operators don’t fix it; the orchestration and chat-UI tiers ship authenticated and operators leave that default in place. The shift between layers is sharp. Open WebUI fits the orchestration/UI pattern, auth defaults are respected, but introduces a new failure mode (open-signup misconfiguration) that doesn’t exist for headless backend services.

Remediation

For Open WebUI operators with public signup unintentionally enabled:

# docker-compose.yml - environment variables to set
environment:
  - ENABLE_SIGNUP=False              # disable public registration
  - DEFAULT_USER_ROLE=pending        # new users require admin approval
  - WEBUI_AUTH=True                  # ensure auth is on (default)
  # optional: restrict signup by allowed-domain
  - WEBUI_SIGNUP_ALLOWED_DOMAINS=yourcompany.com

For operators on old Open WebUI versions (0.3.x – 0.6.x): upgrade to current 0.9.x. The release notes from 0.6 → 0.9 include several auth/permission improvements.

Branded-fork operators (Lexa, Chatty AI, InsightERA CorpGPT): cross-check that fork upstream has merged Open WebUI’s recent auth-related fixes.

NuClide Pipeline Artifacts

Cross-Referenced Survey: Marqo (port 8882): Zero Confirmed

A parallel masscan of port 8882 (Marqo’s default) across the same 28 cloud /16 ranges produced 2,952 hits, but /indexes probes against those hits returned zero confirmed Marqo instances. Sample-host inspection of the surface revealed:

• ~80% of hits time out on TCP HTTP probes (TCP-open at masscan layer but RST/drop on actual HTTP)
• Detected honeypot signatures on at least one (Server: 360 web server, TELDAT, A10WS, characteristic T-Pot vector-DB-honeypot fake)

Marqo as a self-hosted product is rare on cheap cloud VPSes, the vast majority of Marqo deployments are either Marqo Cloud (managed) or behind reverse proxies that hide port 8882 from the public internet. No Marqo findings to report.

References

• Open WebUI auth configuration: https://docs.openwebui.com/getting-started/env-configuration#authentication
• Open WebUI release notes: https://github.com/open-webui/open-webui/releases
• Cross-survey index: index.md