Summary
Flowise contains missing route-level authorization checks on chat message endpoints, allowing low-privileged API keys to access chat histories without the permissions associated with the flow. An attacker with a valid insufficiently privileged API key may read prompts and model responses or delete chat messages.
Affected context
The issue occurs in Flowise deployments where chat message GET and DELETE routes rely on API key validity without consistently verifying permissions for the specific flow or resource. Risk is higher when low-privileged keys can reach these endpoints and chat histories contain sensitive prompts, responses, or operational data.
Exploit preconditions
- Attack surface: Flowise chat message API endpoints - Required access: A valid API key with insufficient privileges - Trigger point: Requests to chat history read or deletion routes - Why exploitation is possible: Route-level checks do not consistently
enforce the flow permissions required for the requested chat resource
Why this happens
The underlying flaw is an authorization design gap: endpoint handlers authenticate the API key but do not reliably authorize access to the requested flow and its chat messages. This behavior maps to CWE-862, Missing Authorization, because a sensitive operation can proceed without an effective permission check at the route or resource boundary.
Potential impact
- An attacker may read chat histories containing prompts and model responses.
- Sensitive application, user, or business information could be disclosed.
- An attacker could delete chat messages and disrupt historical records.
- Investigations, auditing, or workflow continuity may be impaired.
General mitigation guidance
Mitigation generally centers on enforcing authorization at every sensitive route and resource boundary, rather than treating API key possession as sufficient access. Permission checks should be evaluated server-side for the requested flow and chat resource, with secure-by-default denial for missing, ambiguous, or invalid permissions. API keys should have narrowly scoped privileges, and systems should reduce trust in caller-supplied identifiers by resolving ownership and permissions from trusted server-side context. Least-privilege service accounts, immutable audit records, and controls separating read and delete capabilities can further limit impact.
How teams detect issues like this
Detection approaches include static analysis and code review for routes that authenticate requests without invoking resource-level authorization, as well as checks for direct use of caller-supplied flow or chat identifiers. API tests can exercise each read and destructive endpoint with keys from different permission tiers and verify default-deny behavior. Policy enforcement can require documented authorization middleware or permission checks on all sensitive routes, while logs and alerts can identify unusual cross-flow access or bulk deletion activity. Automated review tools may help flag missing authorization patterns during development.
