Summary
Flowise exposes server-wide upsert history through an API response that is not adequately scoped to the requesting user, tenant, workspace, or project. An attacker who can access the endpoint may retrieve sensitive integration configuration, including vector-store details and infrastructure identifiers, with the response potentially exceeding 100 MB.
Flowise exposes server-wide upsert history through an API response that is not adequately scoped to the requesting user, tenant, workspace, or project. An attacker who can access the endpoint may retrieve sensitive integration configuration, including vector-store details and infrastructure identifiers, with the response potentially exceeding 100 MB.
Affected context
The issue occurs in Flowise deployments where the /api/v1/upsert-history endpoint is reachable and its results are returned without sufficient authorization or workspace isolation. Risk is increased when upsert history contains integration settings, vector-store connection parameters, collection names, or other operational metadata and when responses are not constrained by pagination or record limits.
The issue occurs in Flowise deployments where the /api/v1/upsert-history endpoint is reachable and its results are returned without sufficient authorization or workspace isolation. Risk is increased when upsert history contains integration settings, vector-store connection parameters, collection names, or other operational metadata and when responses are not constrained by pagination or record limits.
Exploit preconditions
- Attack surface: Flowise's HTTP API, specifically the upsert-history endpoint
- Required access: Network access to the endpoint and any access level required by the deployment; the issue does not reliably enforce data ownership after the request is accepted
- Trigger point: A request to retrieve upsert history
- Why exploitation is possible: Server-side history is returned without adequate user, tenant, workspace, or project scoping, and the response may lack effective pagination or size limits
- Attack surface: Flowise's HTTP API, specifically the upsert-history endpoint
- Required access: Network access to the endpoint and any access level required by the deployment; the issue does not reliably enforce data ownership after the request is accepted
- Trigger point: A request to retrieve upsert history
- Why exploitation is possible: Server-side history is returned without adequate user, tenant, workspace, or project scoping, and the response may lack effective pagination or size limits
Why this happens
The underlying flaw is an authorization and data-isolation failure. The endpoint retrieves a broad server-wide dataset without consistently applying the requester's security context, mapping to CWE-862: Missing Authorization and CWE-202: Exposure of Sensitive Information Through Data Queries. Returning the resulting records without strict pagination or minimization further contributes to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
The underlying flaw is an authorization and data-isolation failure. The endpoint retrieves a broad server-wide dataset without consistently applying the requester's security context, mapping to CWE-862: Missing Authorization and CWE-202: Exposure of Sensitive Information Through Data Queries. Returning the resulting records without strict pagination or minimization further contributes to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor.
Potential impact
- Unauthorized users may access configuration data belonging to other users, tenants, or workspaces
- Exposed Qdrant URLs, collection names, and related parameters could enable targeted follow-on attacks
- Attackers could learn deployment topology, integration choices, and operational metadata
- Very large responses could increase memory, bandwidth, or availability pressure
- Disclosed information could support credential targeting, data access attempts, or broader infrastructure reconnaissance
- Unauthorized users may access configuration data belonging to other users, tenants, or workspaces
- Exposed Qdrant URLs, collection names, and related parameters could enable targeted follow-on attacks
- Attackers could learn deployment topology, integration choices, and operational metadata
- Very large responses could increase memory, bandwidth, or availability pressure
- Disclosed information could support credential targeting, data access attempts, or broader infrastructure reconnaissance
General mitigation guidance
Mitigation generally focuses on enforcing authorization and minimizing the data returned by history APIs.
Common defensive patterns include:
- Apply server-side authorization checks before querying history
- Scope every query to the authenticated user's tenant, workspace, project, and permitted resources
- Deny access by default when ownership or tenancy context is missing or ambiguous
- Return only fields necessary for the requesting feature, excluding secrets and infrastructure-sensitive parameters
- Enforce pagination, maximum page sizes, response-size limits, and bounded query ranges
- Use short-lived, least-privileged service credentials and avoid exposing connection details in operational history
- Log and alert on unusually broad, repeated, or high-volume history requests
Mitigation generally focuses on enforcing authorization and minimizing the data returned by history APIs.
Common defensive patterns include:
- Apply server-side authorization checks before querying history
- Scope every query to the authenticated user's tenant, workspace, project, and permitted resources
- Deny access by default when ownership or tenancy context is missing or ambiguous
- Return only fields necessary for the requesting feature, excluding secrets and infrastructure-sensitive parameters
- Enforce pagination, maximum page sizes, response-size limits, and bounded query ranges
- Use short-lived, least-privileged service credentials and avoid exposing connection details in operational history
- Log and alert on unusually broad, repeated, or high-volume history requests
How teams detect issues like this
Detection can combine application testing, source review, and policy enforcement:
- Use static analysis and code review to identify data queries that do not incorporate authenticated tenant, workspace, project, or user context
- Review route handlers and service-layer methods for missing authorization middleware or post-query ownership checks
- Test requests across users and tenants to verify that records cannot cross isolation boundaries
- Check API contracts for pagination, maximum limits, field allowlists, and response-size controls
- Monitor access logs for unusually large responses, repeated history enumeration, and requests spanning broad time ranges
- Use automated API security testing or policy-as-code checks to validate authorization and object-level isolation
Detection can combine application testing, source review, and policy enforcement:
- Use static analysis and code review to identify data queries that do not incorporate authenticated tenant, workspace, project, or user context
- Review route handlers and service-layer methods for missing authorization middleware or post-query ownership checks
- Test requests across users and tenants to verify that records cannot cross isolation boundaries
- Check API contracts for pagination, maximum limits, field allowlists, and response-size controls
- Monitor access logs for unusually large responses, repeated history enumeration, and requests spanning broad time ranges
- Use automated API security testing or policy-as-code checks to validate authorization and object-level isolation
