CVE-2026-90533 in Flowise
Summary
by MITRE • 09/12/2026
Flowise before 3.1.4 contains a broken access control vulnerability in GET /api/v1/organizationuser that allows any authenticated organization member to retrieve the organization owner's full user record including bcrypt password hash and temporary tokens. Attackers can query the endpoint with any user ID to obtain the owner's credential hash for offline cracking, enabling account takeover of the highest-privileged account.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical failure in server-side access control mechanisms within the application's API layer. Specifically, the endpoint GET /api/v1/organizationuser is designed to retrieve user information associated with an organization; however, it lacks proper authorization checks to validate whether the requesting authenticated member has permission to view data belonging to other users, particularly those holding elevated privileges such as organization owners. This flaw allows any authenticated user within the same organizational context to bypass intended restrictions and query arbitrary user identifiers, thereby gaining access to sensitive personal information that should be strictly confined to administrative or self-service contexts only.
From a technical perspective, the core issue lies in the absence of object-level authorization checks when processing requests for specific user records. The application accepts a user ID parameter from the client but fails to verify if the session token associated with the request belongs to an entity authorized to view that particular record's full details. Consequently, by manipulating this identifier to point toward the organization owner’s unique ID, attackers can extract comprehensive profile data including email addresses and, most critically, cryptographic credentials such as bcrypt password hashes and temporary authentication tokens. This behavior indicates a fundamental misunderstanding or misimplementation of role-based access control principles where privilege escalation is achieved not through exploiting code logic errors but simply by abusing insufficient input validation regarding resource ownership.
The operational impact of this vulnerability is severe due to the nature of the exposed data. The retrieval of bcrypt password hashes enables attackers to perform offline brute-force attacks against these credentials without triggering account lockout mechanisms or rate-limiting protections typically associated with online login attempts. Given that many users reuse passwords across multiple services, successful cracking could lead to widespread compromise beyond just the Flowise instance. Furthermore, the exposure of temporary tokens may allow for immediate session hijacking if those tokens are still valid and used elsewhere in the system’s authentication flow. This combination significantly increases the risk profile from simple data leakage to full account takeover of the highest-privileged administrative account within the organization.
This incident aligns with Common Weakness Enumeration (CWE) category CWE-284, which describes Improper Access Control, specifically reflecting scenarios where access control decisions are not enforced properly on sensitive resources. In terms of offensive security frameworks, this vulnerability maps to MITRE ATT&CK technique T1078, Valid Accounts, as it facilitates unauthorized use of legitimate credentials through information disclosure rather than direct exploitation of a buffer overflow or injection flaw. It also relates to CWE-200, Exposure of Sensitive Information to an Unauthorized Actor, highlighting the unintended availability of confidential data to parties lacking appropriate clearance levels within the application’s hierarchy.
To mitigate this vulnerability, immediate patching to version 3.1.4 or later is required as it addresses these authorization gaps in the API endpoint logic. In addition to upgrading, organizations should implement strict server-side validation that ensures users can only access their own profile data unless they possess explicit administrative roles defined by a robust role-based access control model. Security teams must also audit other similar endpoints for analogous flaws where user-specific resources are exposed without adequate ownership verification. Regular penetration testing focusing on broken object level authorization patterns is recommended to identify and remediate such weaknesses before they can be exploited in production environments, ensuring that sensitive data like password hashes remains protected against unauthorized retrieval attempts by lower-privileged users.