CVE-2026-90534 Overview
Flowise is a low-code platform for building large language model (LLM) applications. CVE-2026-90534 is an Insecure Direct Object Reference (IDOR) vulnerability [CWE-639] affecting Flowise versions up to and including 3.1.3. The POST /api/v1/node-load-method/:name endpoint lacks route-level permission checks and resolves credentials by raw Credential.id without validating workspace ownership. An authenticated low-privilege user in one workspace can supply a credential ID owned by another workspace, causing Flowise to act as a confused deputy and issue third-party provider calls using the victim workspace's credentials.
Critical Impact
Cross-workspace credential abuse enables unauthorized third-party API calls and metadata disclosure from services such as Google Drive, Google Sheets, and AWS DynamoDB.
Affected Products
- Flowise versions <= 3.1.3
- FlowiseAI Flowise low-code LLM platform
- Fixed in Flowise version 3.1.4
Discovery Timeline
- 2026-09-12 - CVE-2026-90534 published to NVD
- 2026-09-15 - Last updated in NVD database
Technical Details for CVE-2026-90534
Vulnerability Analysis
The vulnerability resides in the node load method API endpoint, which components use to fetch dynamic input options such as file listings or table names. The route accepts attacker-controlled parameters including nodeName, loadMethod, inputs, and credential values in the request body.
When a request arrives, Flowise invokes getCredentialData() using the raw Credential.id supplied by the caller. The function decrypts the credential secret and passes it to the component's load method. Unlike other credential read paths in the application, this flow never checks that Credential.workspaceId matches the caller's active or shared workspace.
Statically identified affected load methods include Google Drive listFiles, Google Sheets listSpreadsheets, and AWS DynamoDB KV Storage listTables. The raw credential secret is not returned to the attacker, but provider metadata retrieved with the victim's credential is returned in the response.
Root Cause
The root cause is missing authorization enforcement on cross-workspace object references [CWE-639]. Other credential retrieval paths in Flowise scope lookups by workspace context, but node-load-method resolves credentials solely by ID. The endpoint also lacks any route-level permission middleware.
Attack Vector
An authenticated low-privilege user or a workspace API key holder sends a crafted POST request to /api/v1/node-load-method/:name. The attacker specifies a target component (for example, a Google Drive node), the intended loadMethod, and a credential field containing a credential ID belonging to another workspace. Flowise decrypts and uses the victim credential, executes the provider call, and returns metadata to the attacker. See the VulnCheck Advisory on IDOR for endpoint details.
Detection Methods for CVE-2026-90534
Indicators of Compromise
- Requests to POST /api/v1/node-load-method/:name where the credential value corresponds to a credential owned by a workspace other than the caller's active workspace.
- Unexpected third-party provider API calls (Google Drive, Google Sheets, AWS DynamoDB) originating from Flowise using credentials that were not initiated by the credential's owning workspace.
- Provider-side audit log entries showing listFiles, listSpreadsheets, or listTables operations at times not correlated with legitimate workspace activity.
Detection Strategies
- Correlate Flowise application logs with the workspaceId of the calling session and the workspaceId recorded on the resolved credential; flag any mismatch on node-load-method requests.
- Monitor for enumeration patterns where a single user issues repeated node-load-method calls with varying credential IDs, indicating credential ID guessing.
- Alert on any invocation of getCredentialData() in code paths that lack a preceding workspace authorization check.
Monitoring Recommendations
- Enable verbose audit logging on the Flowise API tier and forward logs to a centralized SIEM for cross-workspace access analysis.
- Enable audit logging in connected third-party providers (Google Workspace Admin logs, AWS CloudTrail) and correlate provider events with Flowise request logs.
- Track credential usage frequency per credential ID; investigate spikes originating from workspaces that do not own the credential.
How to Mitigate CVE-2026-90534
Immediate Actions Required
- Upgrade Flowise to version 3.1.4 or later, which enforces workspace scoping on the node-load-method endpoint.
- Rotate all credentials previously stored in Flowise that could have been referenced cross-workspace, including Google Drive, Google Sheets, and AWS DynamoDB credentials.
- Review third-party provider audit logs for unauthorized listFiles, listSpreadsheets, and listTables operations during the exposure window.
Patch Information
The issue is fixed in Flowise version 3.1.4. Upgrade guidance and the full advisory are available in the GitHub Security Advisory GHSA-hqvm-7539-v83j.
Workarounds
- If immediate patching is not possible, restrict access to the Flowise API to trusted operators only using network-level controls or reverse-proxy authentication.
- Deploy each workspace or tenant on a dedicated Flowise instance so that credential IDs cannot be referenced across trust boundaries.
- Apply a reverse-proxy rule that blocks or heavily rate-limits POST /api/v1/node-load-method/* requests until the upgrade is applied.
# Example nginx rule to restrict node-load-method until upgrade to 3.1.4
location ~ ^/api/v1/node-load-method/ {
allow 10.0.0.0/8; # trusted admin subnet
deny all;
proxy_pass http://flowise_backend;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

