CVE-2026-70473 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise GET /api/v1/upsert-history returns the entire server-wide upsert history instead of being scoped to the requesting user, tenant, or workspace. The response can exceed 100MB and includes sensitive configuration data, including Vector Store settings such as Qdrant Server URL and collection name. The observed behavior indicates missing or insufficient authorization checks, workspace/project/tenant isolation, and pagination or limits, exposing integration parameters and infrastructure details that may enable further targeted attacks. This issue is fixed in version 3.1.3.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/04/2026
The vulnerability in Flowise versions prior to 313 represents a critical access control flaw that undermines the security boundaries of multi-tenant environments. This issue manifests through the GET /api/v1/upsert-history endpoint which fails to properly scope responses to individual users, workspaces, or tenants. The exposed data includes comprehensive upsert history information that can exceed 100 megabytes in size, containing sensitive configuration parameters that are typically restricted to authorized personnel only.
The technical implementation flaw stems from inadequate authorization checks within the API layer, specifically missing or insufficient validation of user context during request processing. This allows any authenticated user to access server-wide historical data that should be isolated to their specific workspace or tenant environment. The vulnerability is classified under CWE-285 which addresses improper authorization in software systems, where the application fails to verify that the requesting entity has sufficient privileges to access requested resources.
The operational impact of this vulnerability extends beyond simple information disclosure, as it exposes infrastructure details including Qdrant Server URL and collection names that provide attackers with critical integration parameters. These exposed elements can serve as entry points for further reconnaissance and targeted attacks against the underlying vector storage systems. The lack of pagination or size limits in the API response amplifies the risk by allowing potentially massive data dumps to be retrieved without restriction, creating opportunities for data exfiltration and system enumeration.
The absence of proper workspace or tenant isolation mechanisms creates a significant security gap in Flowise's multi-tenant architecture, where user data should remain compartmentalized. This flaw aligns with ATT&CK technique T1566 which covers credential access through unauthorized access to systems, and T1083 which involves discovery of files and directories. Attackers could leverage this vulnerability to gather intelligence about other users' configurations and infrastructure, potentially identifying additional targets for exploitation.
The fix implemented in version 3.1.3 addresses the core authorization issue by properly scoping API responses to individual user contexts while maintaining appropriate pagination limits. This remediation ensures that each user only receives upsert history data relevant to their specific workspace or tenant, preventing unauthorized access to cross-tenant information. The implementation should include proper session validation, context-aware resource filtering, and rate limiting mechanisms to prevent abuse of the API endpoint.
Organizations using Flowise should immediately upgrade to version 3.1.3 or later to remediate this vulnerability, while also implementing additional monitoring for unusual API access patterns that could indicate exploitation attempts. Security teams should review existing access controls and ensure proper isolation mechanisms are in place for all multi-tenant applications. The vulnerability demonstrates the importance of proper authorization checking in API implementations and highlights the need for comprehensive security testing of data exposure points in LLM-based applications.
This issue serves as a reminder of the critical security considerations when developing multi-tenant systems where access control must be enforced at every level of the application stack, from user authentication through to data retrieval operations. The vulnerability's resolution emphasizes the importance of implementing proper resource scoping and authorization checks in all API endpoints, particularly those handling historical or configuration data that may contain sensitive infrastructure details.