ZoomEye queries surface 40,653 Flowise and 10,860 Dify AI builder title matches

What the scan found

A dev.to post published on 10 October 2026 reports large numbers of internet-reachable pages belonging to two low-code AI application builders. Queries run against the ZoomEye cyberspace search engine on 28 September 2026 returned 40,653 results for pages titled "Flowise" and 10,860 results for pages titled "Dify".

Both products let teams assemble language-model workflows — prompts, tools and data sources — through a web interface, and both store the credentials those workflows use. The author frames the findings as a new exposure class assembled from familiar parts: a web application holding secrets, stood up quickly by a small team, on a host reachable from the open internet.

What the platforms hold

According to the post, the stored material is what makes the exposure significant rather than the raw counts. A typical workflow includes a model provider key — a billable credential that works from any location — and may also contain database connections, object storage keys and API tokens for the services the workflow calls. The platforms additionally keep the prompts themselves and knowledge base content, which frequently reflects internal documentation.

The author points out that combining a model key with indexed documents creates a data-disclosure path: an attacker holding the key can issue queries against the knowledge base the platform has indexed, and the underlying documents can come back in the response.

Why instances end up exposed

The typical deployment pattern, as the post describes it, starts with a container image on a small host, published on a port so colleagues can reach it during an evaluation. That evaluation host then becomes the production instance, and the port stays open. Both platforms offer authentication, but their default configurations prioritise getting started, and the feature is not always switched on.

Suggested review steps

The post lays out a four-step review sequence for teams running either platform:

• Confirm authentication is enabled and that the initial account credentials were changed at deployment time.
• Inventory the stored credentials, starting with model provider keys, and rotate any that may have been exposed.
• Restrict network reachability to the users and systems that genuinely need it, and place the interface behind an access proxy rather than publishing the port directly.
• Audit the indexed documents to see what read-only access to the platform would reveal, since that is the realistic impact of a credential compromise here.

Caveats in the numbers

The figures come with clear limits. The queries do not report whether authentication is enabled on any given host, and both product names appear in documentation, tutorials and marketplace listings, so the totals include pages that are not running services. At the same time, deployments often use an obfuscated page title, which means the measured population likely understates the real one. The author's own guidance is to treat the counts as directional signal rather than an inventory.

Why it matters

Low-code AI builders concentrate exactly the assets attackers want: billable model provider keys, service credentials and internal documents, all behind a single web interface whose defaults favour convenience over access control. The Flowise and Dify numbers suggest this pattern is appearing at scale as teams adopt LLM tooling faster than they harden it. The fix is also unusually cheap relative to the risk — enabling authentication, rotating keys and moving the interface behind a proxy amount to hours of work — which makes this a practical checklist item for anyone running these platforms in production.