DEV Community

StarkMan
StarkMan

Posted on

Chat Front Ends Are the Quiet Part of AI Exposure: 90,330 Open WebUI Instances

#security #ai #exposure #zoomeye

Chat Front Ends Are the Quiet Part of AI Exposure: 90,330 Open WebUI Instances

Model servers get attention because they run the models. The interfaces layered on top of them tend to get less, even though they hold the sessions, the prompt history and the connection details. A ZoomEye query for app="Open WebUI" returned 90,330 matching assets on 4 October 2026, which is a useful reminder that the control plane is its own attack surface.

What sits behind a chat interface

Open WebUI is a self-hosted front end that connects to one or more model backends. Once configured, it knows the backend addresses, the API keys used to reach them, and the conversations users have had. In a small deployment that may be one administrator's notes and a handful of test prompts. In a larger one it can be a shared workspace where staff paste source code, incident notes or customer data to get help with it.
The NCSC assessment notes that AI will almost certainly make attacks against the United Kingdom more impactful, partly because exfiltrated data can be analysed faster and then used to train further models. A chat front end is a convenient collection point for exactly that kind of material, because it concentrates text that people already treat as work product.

Why the count is a starting point, not a finding

90,330 assets matching an application fingerprint is a measure of reachable software. It does not distinguish between a login page and an open instance, and it says nothing about who can reach each host. The same caution applies to the other counts in this series. Fingerprints describe what a service presents to a scanner.
What the number does support is prioritisation. If an organisation runs this software, the question worth asking is whether its instance is among the reachable ones and whether the login path is the only way in.

Using ZoomEye to narrow the question

The broad query establishes scale. Narrowing it makes the result actionable:

  • Add country or org to turn a global count into a list that matches the organisation's own footprint.

  • Combine the fingerprint with a service or port condition to separate the default listener from a reverse-proxied deployment.

  • Compare two runs a few weeks apart. A rising count in a defined scope is a signal to check whether a new instance was published by accident.

Hardening the control plane

Authentication in front of the interface is the baseline, and it should be enforced at a gateway rather than left to the application's own settings. Session storage deserves the same scrutiny as the model backend, because conversation history is often the most sensitive data in the deployment. Where the interface is only needed internally, a private listener plus a VPN removes it from public reach entirely, and that is the configuration least likely to drift.

Limits of scan-derived evidence

Exposure counts cannot tell a reader whether an instance stores conversations for a long period, whether it forwards prompts to a third-party provider, or whether the operator intends it to be public. Those are configuration questions answered by reading the deployment, not by searching. Presenting a scan count as evidence of a data leak would overstate what the data shows.

References

Top comments (0)