CVE-2026-70472 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise openai-assistants-vector-store endpoints accept a client-controlled credential parameter and load credentials by id without checking whether that credential belongs to the caller workspace. Route permissions assistants:* only check feature access. The controller passes req.query.credential straight to the service, and the service uses findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs without a workspaceId check. If an attacker knows another workspace credentialId, the attacker can use that workspace OpenAI key, read, modify, or delete victim vector stores and files, cause billing impact on the victim OpenAI account, and violate multi-tenant boundaries. 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
Flowise represents a significant security vulnerability in its handling of OpenAI assistant vector store operations that stems from inadequate access control mechanisms and credential validation procedures. The flaw exists in versions prior to 3.1.3 where the system fails to properly authenticate and authorize credential usage within multi-tenant environments. This vulnerability manifests through the openai-assistants-vector-store endpoints which accept client-controlled credential parameters without verifying whether these credentials belong to the requesting user's workspace, creating a critical authorization bypass that undermines the fundamental security boundaries of the platform.
The technical implementation of this vulnerability follows a clear attack pattern where route permissions for assistants:* only validate feature access rather than enforcing proper credential ownership checks. The controller layer directly passes req.query.credential to the service layer without any validation or workspace context verification, allowing malicious actors to exploit the system's trust model. The service layer then executes findOneBy({ id: credentialId }) to retrieve credentials, decrypts them, and proceeds to call OpenAI APIs without performing a workspaceId check that should validate ownership relationships. This design flaw creates a direct path for credential theft and unauthorized access to other workspaces' resources.
The operational impact of this vulnerability extends far beyond simple unauthorized access, creating substantial financial and data integrity risks for affected users. Attackers who discover valid credentialIds from other workspaces can leverage these credentials to perform read, modify, or delete operations on victim vector stores and files, potentially causing significant data loss or corruption. The most concerning aspect involves the billing implications where attackers can consume OpenAI service credits from victim accounts, creating unauthorized charges that may go unnoticed for extended periods. This vulnerability fundamentally violates multi-tenant security boundaries by allowing cross-workspace credential access, effectively enabling privilege escalation attacks that compromise the isolation guarantees expected in multi-tenant platforms.
This vulnerability aligns with several established cybersecurity frameworks and threat models, particularly CWE-285 which addresses improper authorization scenarios, and relates to ATT&CK technique T1078 for valid accounts usage. The flaw represents a classic case of insufficient input validation combined with weak access control enforcement, creating a path for attackers to exploit trust relationships within the system. Organizations implementing Flowise must recognize this as a critical security issue that requires immediate remediation through proper credential ownership verification and workspace boundary enforcement.
The mitigation strategy involves implementing comprehensive workspace validation checks before credential usage, ensuring that all credential operations verify ownership relationships and enforce proper authorization boundaries. Version 3.1.3 addresses this by introducing mandatory workspaceId checks during credential retrieval processes, preventing cross-workspace credential access while maintaining legitimate multi-tenant functionality. Organizations should also implement additional monitoring for unauthorized credential usage patterns and establish robust credential lifecycle management practices to minimize the exposure window for potentially compromised credentials.