What happened
Flowise (low-code LLM application platform) versions up to and including 3.1.3 mount the POST /api/v1/node-load-method/:name endpoint without any route-level permission check. The endpoint invokes component loadMethods with attacker-controlled nodeName, loadMethod, inputs, and credential value; the selected credential is resolved by raw Credential.id and decrypted without verifying Credential.workspaceId against the caller's active workspace (unlike other credential-read paths, which are workspace-scoped). An authenticated low-privilege user in one workspace can supply a credential ID belonging to another workspace, causing Flowise to act as a confused deputy and perform third-party provider API calls (e.g., Google Drive listFiles, Google Sheets listSpreadsheets, AWS DynamoDB listTables) using the victim workspace's credential, returning provider metadata to the attacker. The raw credential secret itself is not returned.
Why it matters
Flowise is a widely-adopted platform for building LLM/RAG applications with multi-tenant workspace isolation; this flaw breaks that isolation boundary, letting any authenticated user in one tenant silently invoke privileged third-party API calls using another tenant's stored LLM/cloud provider credentials — a direct cross-tenant confidentiality breach in a commonly self-hosted AI orchestration tool.
Attack vector
Authenticated low-privilege user (or workspace API key) sends a crafted POST to /api/v1/node-load-method/:name supplying another workspace's credential ID, causing the server to decrypt and use that credential for a third-party provider call without workspace-ownership verification.
Affected systems
Flowise <= 3.1.3
Mitigation
Upgrade to Flowise 3.1.4 or later, which adds workspace-scoped verification to the node-load-method credential resolution path.