CVE-2026-90534 in Flowise
Summary
by MITRE • 09/12/2026
Flowise is a low-code platform for building LLM applications. In versions up to and including 3.1.3, the POST /api/v1/node-load-method/:name endpoint is mounted without any route-level permission check and invokes component loadMethods with an attacker-controlled nodeName, loadMethod, inputs, and credential value. The selected credential is resolved by raw Credential.id via getCredentialData() and decrypted without verifying Credential.workspaceId against the caller's active or shared workspace, unlike other credential read paths which are workspace-scoped. As a result, an authenticated low-privilege user (or workspace API key) in one workspace can supply a credential ID owned by another workspace and cause Flowise to act as a confused deputy, performing third-party provider calls with the victim workspace's credential and returning provider metadata to the attacker. Statically identified affected load methods include Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. The raw credential secret itself is not returned to the attacker. This issue is fixed in version 3.1.4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability resides within Flowise, a low-code platform designed for constructing large language model applications, specifically affecting versions up to and including 3.1.3. The core technical flaw lies in the POST /api/v1/node-load-method/:name endpoint, which is mounted without implementing necessary route-level permission checks. This architectural oversight allows authenticated users with low privileges or those utilizing workspace API keys to manipulate critical parameters such as nodeName, loadMethod, inputs, and credential values. Unlike other credential retrieval paths within the application that enforce strict workspace-scoped access controls, this specific endpoint resolves credentials using a raw Credential.id via the getCredentialData function without validating whether the requested credential belongs to the caller's active or shared workspace. This discrepancy in authorization logic creates a significant security gap where the system fails to verify the ownership of the resource being accessed against the identity and permissions of the requesting entity.
This flaw effectively manifests as an instance of confused deputy syndrome, wherein Flowise acts on behalf of one user but performs actions using credentials belonging to another workspace due to insufficient validation of context. An attacker can exploit this by supplying a credential ID that is owned by a different, victim workspace. Consequently, the application processes requests and invokes third-party provider calls using the victim's sensitive authentication data. While the vulnerability does not result in the direct exfiltration of raw credential secrets such as API keys or passwords to the attacker, it allows for unauthorized access to metadata and operational information from external services. Specifically, statically identified affected load methods include Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. Through these endpoints, an attacker can enumerate files, spreadsheets, or database tables belonging to other workspaces, thereby gaining visibility into the structure and contents of resources they should not have access to.
The operational impact of this vulnerability is primarily centered on information disclosure and potential reconnaissance for further attacks. By accessing metadata from external providers like Google Workspace and AWS services, an attacker can map out the digital footprint of a target organization or other workspace users. This intelligence could be used to identify valuable targets, understand data storage patterns, or plan more sophisticated intrusion attempts that leverage knowledge gained from this initial access phase. Although no direct credential theft occurs in this specific vector, the ability to read sensitive metadata undermines the principle of least privilege and compromises the isolation guarantees between different workspaces within a multi-tenant deployment environment. This erosion of trust can lead to compliance violations if such data contains personally identifiable information or regulated business secrets.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves unauthorized access to resources due to flawed permission checks. It also relates closely to CWE-798 Use of Hard-coded Credentials in the context of misusing credential identifiers across workspace boundaries, and potentially CWE-601 URL Redirection to Untrusted Site if interpreted broadly within authentication flows, though the primary issue is authorization bypass. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1538.002 Cloud Service Dashboard Reflection, where an attacker uses a service's API or interface to gather information about other entities' resources without direct access rights being properly enforced by the platform itself. It also touches upon T1078 Valid Accounts if low-privilege accounts are leveraged to perform actions outside their intended scope through this misconfigured endpoint.
To mitigate this vulnerability, organizations running Flowise must immediately upgrade to version 3.1.4 or later, where the route-level permission checks have been implemented and workspace isolation logic has been corrected for credential resolution. For environments that cannot update immediately due to operational constraints, network-level controls such as web application firewalls can be configured to restrict access to the /api/v1/node-load-method endpoint based on known legitimate traffic patterns or IP ranges, although this is a less robust defense than patching the underlying code. Additionally, administrators should review their workspace configurations and ensure that API keys are scoped strictly to necessary permissions with minimal privileges. Regular security audits focusing on authorization logic across all API endpoints are recommended to detect similar inconsistencies in other parts of the application before they can be exploited.