LiteLLM, Flowise, Open WebUI: your AI stack's admin panel is holding every provider key

You stood up an LLM gateway over a weekend. LiteLLM in front of OpenAI and Anthropic so you could swap models without touching app code, maybe Flowise to wire up an agent visually, an Open WebUI for the team to chat with. It works, it's on a public host so the team can reach it, and the admin login is on a password you set in five seconds and never changed. That panel is now holding your provider keys, your prompts, and your data, and it's answering anyone who finds the URL.

This is the 2026 version of an exposed admin panel, and it's worth its own attention because of what these tools concentrate. An LLM gateway exists specifically to centralize your API keys. A self-hosted agent builder exists to store credentials inside its flows. The whole point of the tooling is to hold the expensive, sensitive things in one place, which is exactly what makes the panel in front of it a target.

Four tools, one shape of exposure

Different jobs, same problem: the control surface for your AI stack, reachable without auth.

• LiteLLM Proxy is the gateway. Its dashboard manages the upstream provider keys (OpenAI, Anthropic, Azure), the virtual keys you hand to apps, per-key budgets, and the spend logs. An attacker who reaches the admin reads your real provider keys and runs your accounts up, or mints virtual keys for themselves. The scanner identifies it by the LiteLLM dashboard title plus its distinctive asset path.
• Flowise is a visual builder for LLM apps and agents. The credentials your flows use, provider keys, database connections, third-party tokens, live inside Flowise. Worse, older versions let the first visitor become the admin, so an exposed instance with no account yet is a free takeover.
• Open WebUI is the self-hosted chat front-end, with model management, a RAG document store, and everyone's conversation history. Open signup left on means the first stranger to load it becomes admin and reads the lot.
• Qdrant is a vector database, and its web console browses the collections. Those collections are usually the chunked text from your RAG pipeline, internal docs, customer data, whatever you embedded, sitting in plain, queryable form.

The common thread is that "logged in" to any of these means access to either the keys that cost money or the data you fed the model. There's no low-stakes version.

What a stranger does with each

Walk it through. A reachable LiteLLM admin is your provider keys, so the immediate move is theft and free spend on your bill, plus the virtual-key system to set up persistent access. A Flowise instance is the credentials baked into flows, and if it's a fresh one, the admin seat itself. Open WebUI is the conversation history and the document store, which on most internal deployments means business data and whatever got pasted into a prompt. Qdrant is the embedded corpus, readable as text. None of these requires an exploit; they require finding the URL and getting past a login that's often weak or absent.

These belong behind the wall

The fix is the same as every operator tool: it shouldn't answer the public internet at all. Put the panel on an internal network or a VPN, and reach it through an SSH tunnel when you need it. The team's convenience of "just hit the URL" is the exact thing an attacker is counting on.

# llm.yoursite.com answers the open internet
# the admin login (and the provider keys behind it) face everyone

If a panel was public, assume the keys it held are compromised and rotate them, the provider keys in LiteLLM, the credentials in your Flowise flows. Turn off open signup on Open WebUI so the first visitor can't claim admin. And keep these patched; fast-moving young projects accrue CVEs quickly.

Reading it from outside

Whether your AI stack's admin answers a stranger is settled by loading its URL, which is what SurfaceCheckr does, from outside, with no credentials. Each probe needs two of the product's own served markers to match, the dashboard title plus a distinctive asset or runtime variable, so it confirms the real panel and won't fire on a marketing page that names the tool. It reads only what the panel serves anonymously and stops there: no login attempt, no API call, nothing active. These sit alongside the older internal tools and dashboards worth checking, and the keys they hold are the same ones that turn up loose in a frontend bundle when an AI app ships fast.