Flowise exposure requires more than turning on application login

#zoomeye #flowise #ai

Flowise exposure requires more than turning on application login

Flowise lets teams build chatflows and agent workflows visually. A self-hosted instance may contain prompts, model credentials, custom code nodes, file-processing tools, and API integrations. Application-level authentication and chatflow-level authorization are useful controls, but they do not automatically define which workflows may run code, which credentials they can reach, or whether the administrative interface belongs on the public internet.

At about 23:48 UTC on 29 October 2026, count-only ZoomEye SDK queries with sub_type=all and page size 1 returned 40,491 matches for app="Flowise" and 41,960 for title="Flowise". The title query is the primary observation here because it is slightly larger, but the two fields may represent different matching conditions. Neither count confirms a vulnerable version or an unauthenticated deployment.

Treat the chatflow as a workload

Application login protects the Flowise interface. Chatflow-level API keys restrict access to a specific chatflow. That is not the same as restricting what the chatflow does after a request is accepted. A flow with an HTTP request node, a custom JavaScript node, or a credential-bearing model integration can reach systems outside the Flowise server. The caller's authorization should match what the flow can do, even when the flow's name suggests a narrower purpose.

Create a separate flow for each business purpose and data boundary. Give each one the smallest model and tool credentials it needs. Disable or tightly review custom code execution where it is not necessary, and constrain outbound network access from the Flowise worker. If a flow accepts file uploads, apply the archive and content limits described for any untrusted input. If it accepts a URL for retrieval, prevent access to internal addresses and cloud metadata paths.

Harden the application boundary

Enable application authentication through the supported environment configuration and test the login path from outside the expected network. Define a strong token hashing secret and keep it out of the web root and source repository. Review how the deployment stores its encryption key and API keys, because those secrets may authorize access to model providers and tools.

Use a reverse proxy or identity-aware gateway for the admin interface when possible. Require MFA at the identity provider, restrict allowed source networks, and log both successful and failed authentication. Place the Flowise API behind a separate route with rate limits and a request-size limit. Do not let a public chat endpoint inherit the administrator's broader network access.

Inventory without probing credentials

For an authorized inventory, compare internet fingerprints with DNS ownership, cloud tags, certificate names, and deployment records. Verify the version from an authenticated administrative path rather than sending exploit traffic. Record the public routes, authentication challenge, TLS configuration, and owner. If a matching asset is not in the inventory, treat it as a discovery task before running a configuration test.

ZoomEye's value here is coverage and comparison. A team can look for Flowise fingerprints across address space and then ask whether its own deployment appears where expected. The count is not a risk score. It says the product name is observable in a broad index. The operational question remains whether the specific instance exposes a console, an API, or a workflow with unnecessary authority.

Define a review checklist

Is the console reachable from the internet?
Which identity provider authenticates administrators?
Are application login and per-chatflow keys enabled?
Which flows can execute custom code or make arbitrary outbound requests?
Which model and tool credentials can each flow read?
Are logs retained for flow changes, key rotation, and failed authorization?
Can an operator revoke a flow and its credentials without rebuilding the whole instance?

If a flow is public, test it like an untrusted API: send malformed input, attempt an unapproved destination, and verify that the expected denial occurs. Do not rely on a UI setting alone. The workflow's network and credential boundaries determine the result of a successful request.

Flowise makes automation accessible to teams that may not run a separate application platform. That is useful, and it increases the importance of ownership. A chatflow list should be a maintained inventory, not an undocumented collection of active integrations.