CVE-2026-90534

Flowise, an open-source low-code platform for building LLM applications, exposes the POST /api/v1/node-load-method/:name endpoint without a route-level permission check and passes attacker-controlled nodeName, loadMethod, inputs, and credential value into component load methods. The credential is resolved by its raw ID via getCredentialData() and decrypted without verifying that its workspaceId matches the caller's active or shared workspace, unlike other credential read paths which are workspace-scoped. As a result, any authenticated low-privilege user or workspace API key in one workspace can supply a credential ID belonging to another workspace, turning Flowise into a confused deputy that performs third-party provider calls (e.g., Google Drive listFiles, Google Sheets listSpreadsheets, AWS DynamoDB listTables) using the victim's credential and returns the resulting provider metadata to the attacker, though the raw secret itself is not disclosed. All users of self-hosted Flowise deployments up to and including version 3.1.3 with multiple workspaces or shared instances are affected; the issue is fixed in version 3.1.4. Exploitation status: a public vendor security advisory exists but EPSS is very low (0.2%) and no in-the-wild exploitation is known.

What to do: Upgrade Flowise to version 3.1.4 or later, which enforces workspace scoping on the node-load-method credential path. Review application and provider-side logs for anomalous load-method calls (Google Drive/Sheets listing, DynamoDB listTables) originating from users or API keys outside the credential's owning workspace, and rotate affected provider credentials if abuse is suspected. Until patched, restrict access to the API at the network layer and limit which users can obtain workspace API keys.