CVE-2026-91929 in Flowise
Summary
by MITRE • 09/15/2026
Flowise versions before 3.1.4 contain cross-tenant authorization gaps in Enterprise endpoints that fail to verify resource ownership before operations. Attackers with Enterprise access can delete arbitrary workspaces, invite themselves into other organizations, modify cross-org roles, and abuse stored SSO secrets.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical failure in multi-tenant security architecture, specifically manifesting as broken access control within the Enterprise edition's API endpoints. This flaw stems from an insufficient verification of resource ownership during state-changing operations. In a properly secured enterprise environment, every request that modifies data or configuration must be rigorously validated against the identity and permissions of the requesting user to ensure they possess explicit authorization for the specific target resource. However, in these affected versions, the backend logic fails to enforce this boundary check effectively. Consequently, an authenticated attacker who possesses valid Enterprise credentials can manipulate API parameters to bypass tenant isolation mechanisms. This architectural weakness allows actions intended for one organization's context to be executed against resources belonging to entirely different organizations or workspaces within the same Flowise instance.
The operational impact of this vulnerability is severe and multifaceted, leading to potential data loss, unauthorized access escalation, and compromise of sensitive authentication configurations. Attackers can exploit these gaps to delete arbitrary workspaces, effectively causing denial of service for legitimate users and resulting in permanent loss of configuration history or application logic stored within those environments. Furthermore, the ability to invite oneself into other organizations grants lateral movement capabilities across the multi-tenant infrastructure. This allows an attacker with access to a lower-level tenant to elevate their privileges by gaining entry into higher-value organizational units where more sensitive data or critical applications may reside. The modification of cross-org roles further exacerbates this risk, as it enables the alteration of permission sets for other users, potentially granting administrative control over shared resources without proper oversight.
A particularly dangerous aspect of this vulnerability is the abuse of stored Single Sign-On (SSO) secrets. These credentials are typically used to authenticate Flowise with external identity providers and often hold high privileges within those third-party systems. By accessing or modifying these secrets across tenant boundaries, an attacker can not only compromise the integrity of the Flowise instance but also pivot into connected enterprise ecosystems such as Azure AD, Okta, or Google Workspace. This creates a chain reaction where compromising one organization's SSO configuration could lead to broader identity theft and unauthorized access in external services that trust those credentials. The combination of workspace deletion, lateral movement via invitation manipulation, role modification, and credential exposure constitutes a high-severity threat vector that undermines the fundamental security guarantees expected from enterprise-grade software.
To mitigate these risks, organizations running Flowise Enterprise must immediately upgrade to version 3.1.4 or later, where these authorization checks have been corrected to enforce strict resource ownership validation on all affected endpoints. Until an upgrade is feasible, administrators should implement network-level controls such as Web Application Firewalls (WAFs) with custom rules that inspect API payloads for signs of tenant ID manipulation in cross-org requests. Additionally, it is crucial to rotate any SSO secrets and credentials associated with the Flowise instance immediately after patching or isolating the vulnerable environment, assuming a compromise may have occurred during the window of exposure. Continuous monitoring of audit logs for unusual patterns such as rapid workspace deletions, unexpected user invitations across organizational boundaries, or modifications to role assignments outside normal administrative workflows can help detect exploitation attempts in real time. Adhering to these remediation steps aligns with industry best practices outlined by CWE-284 regarding Improper Access Control and mitigates the risks associated with ATT&CK techniques T1078 Valid Accounts and T1539 Steal Web Session Cookie, ensuring that multi-tenant isolation remains intact.