Description

Flowise through 3.1.4 exposes GET /api/v1/upsert-history/:id and PATCH /api/v1/upsert-history without route-level permission checks, and the backing service performs no workspace or ownership validation. getAllUpsertHistory() returns UpsertHistory rows selected solely by an attacker-supplied chatflowid, and patchDeleteUpsertHistory() deletes rows by an attacker-supplied array of record UUIDs. As a result, any authenticated low-privilege user or valid API key can read or delete document-store upsert history belonging to other users and other workspaces whenever the target chatflowId (which is exposed publicly in /chatbot/<chatflowId> share links) or row ids are known. The retrievable flowData and result fields contain embedding, record-manager and vector-store node configuration, including per-node paramValues. No patched version is available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-26T14:16:41.460Z",
  "pubdate": "2026-09-26T14:16:41.460Z",
  "executiveSummary": "Flowise versions through 3.1.4 contain a broken access control vulnerability in the upsert-history API endpoints.\nThe vulnerability allows authenticated users or entities with a valid API key to perform unauthorized read and delete operations on upsert history records across different workspaces and user accounts.\nThe root cause is a lack of route-level permission checks combined with a complete absence of workspace or ownership validation within the underlying service logic.\nAn attacker can leverage publicly exposed chatflow IDs to retrieve sensitive configuration data, including embedding, record-manager, and vector-store node parameters, or delete arbitrary records using known UUIDs.\nThe risk is critical as it bypasses logical isolation between users, potentially exposing confidential vector store configurations and disrupting historical data integrity.\nExploitation requires minimal privilege, as any authenticated user within the environment can access these records globally regardless of ownership.",
  "technicalDetails": "The vulnerability resides within the API endpoints 'GET /api/v1/upsert-history/:id' and 'PATCH /api/v1/upsert-history', which facilitate interaction with the upsert history of Flowise chatflows.\nIn the affected versions, the implementation of 'getAllUpsertHistory()' and 'patchDeleteUpsertHistory()' fails to enforce boundary conditions for data access.\nThe application relies on user-supplied input—specifically the 'chatflowid' for retrieval and an array of record UUIDs for deletion—without validating whether the requesting identity has authorized access to the associated workspace or resource.\nBecause 'chatflowid' values are often exposed via public share links (e.g., '/chatbot/<chatflowId>'), they are readily discoverable by unauthorized parties.\nAn attacker can exploit this by crafting HTTP requests targeting the vulnerable endpoints. By supplying a target 'chatflowid' in a GET request, the attacker triggers 'getAllUpsertHistory()', which executes a database query that returns all rows associated with that ID, ignoring user-based ownership constraints.\nSimilarly, the PATCH endpoint 'patchDeleteUpsertHistory()' accepts an array of UUIDs. An attacker can enumerate or guess these UUIDs to permanently delete records belonging to any user or workspace within the instance.\nThe data returned in the 'flowData' and 'result' fields includes sensitive information such as embedding model settings, record-manager configurations, and vector-store node parameters, including sensitive 'paramValues'.\nThis leads to significant information disclosure, potentially allowing an attacker to map internal infrastructure, identify vector database access methods, or extract API keys and credentials embedded within node configurations.\nThe attack is authenticated, but the requirement is only for any valid low-privilege user or a valid API key, which is insufficient to maintain multi-tenant or multi-user isolation within the application.\nThere is currently no patched version available, leaving instances vulnerable until manual configuration or network-level access controls are implemented to restrict access to these specific API routes."
}