Summary
Flowise exposes upsert-history endpoints without sufficient route-level authorization, and the backing service does not verify workspace or record ownership. An authenticated low-privilege user or valid API key who knows a target chatflow ID or record UUIDs may read or delete document-store upsert history belonging to other users or workspaces.
Affected context
The issue occurs in Flowise deployments through version 3.1.4 when the upsert-history GET and PATCH routes are reachable and authorization is not enforced at both the route and service layers. Risk is greater when publicly shared chatbot links expose chatflow IDs and when an authenticated account or API key has access to these endpoints without corresponding ownership checks.
Exploit preconditions
- Attack surface: Flowise HTTP API endpoints for upsert-history retrieval and deletion
- Required access: An authenticated low-privilege user or valid API key
- Required knowledge: A target chatflow ID or one or more upsert-history record UUIDs
- Trigger point: GET retrieval or PATCH deletion of upsert-history records
- Why exploitation is possible: The application selects or deletes records using attacker-supplied identifiers without validating workspace membership or ownership
Why this happens
The underlying flaw is missing object-level authorization. The service trusts client-supplied chatflow and record identifiers as sufficient selectors, rather than confirming that each requested object belongs to a workspace and user that the caller is authorized to access. This behavior maps to CWE-639, Authorization Bypass Through User-Controlled Key, and is commonly associated with insecure direct object references.
Potential impact
- An attacker may read upsert-history records belonging to other users or workspaces.
- Retrieved flow data may disclose embedding, record-manager, vector-store, and per-node configuration values.
- An attacker could delete selected document-store upsert-history records.
- The incident may expose configuration details useful for further attacks or operational disruption.
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every
data access layer, not only at the HTTP route.
Common defensive patterns include:
- Require explicit workspace and ownership checks before returning or deleting each record.
- Derive the authorized workspace from the authenticated principal rather than from client-controlled identifiers.
- Apply consistent authorization checks to GET, PATCH, bulk, and indirect service calls.
- Use deny-by-default route policies and narrowly scoped API keys.
- Minimize sensitive configuration data returned in history responses.
- Treat publicly exposed chatflow IDs as identifiers, not authorization credentials.
- Record and review cross-workspace access failures and destructive operations.
How teams detect issues like this
Detection approaches can include:
- Static analysis for database queries or service methods that use request-provided identifiers without nearby authorization checks.
- Code review of every endpoint that accepts chatflow IDs, record UUIDs, workspace IDs, or bulk identifier arrays.
- Tests that attempt same-workspace and cross-workspace reads and deletions using separate principals.
- API gateway or policy controls that require authenticated identity, workspace context, and operation-specific permissions.
- Audit monitoring for unusual enumeration of chatflow identifiers, repeated history access, and bulk deletion requests.
- Neutral automated security review tools may help identify missing object-level authorization patterns.
