Which versions of Flowise are affected by EUVD-2026-52852?

Flowise versions through 3.1.2 fail to enforce workspace isolation on OpenAI credential access, enabling authenticated users to steal other workspaces' API keys and manipulate their AI data.. A patch is available.

Is there a public PoC exploit available for EUVD-2026-52852?

Yes, a public proof-of-concept exploit is available for EUVD-2026-52852. Prioritise patching immediately. EPSS: 0.2%.

How to fix or mitigate EUVD-2026-52852?

Within 24 hours, audit all Flowise deployments to identify current versions and affected workspaces. Within 7 days, obtain the patched version from vendor advisory, test in non-production environments, and stage for deployment. Within 30 days, deploy patched Flowise versions to production following change management controls. In parallel, audit OpenAI API usage logs for unauthorized access and rotate all potentially exposed API keys.

Flowise EUVD-2026-52852

Q: What is the CVSS score of EUVD-2026-52852?

EUVD-2026-52852 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-70472 HIGH

Improper Authorization (CWE-285)

2026-08-04 https://github.com/FlowiseAI/Flowise

GHSA-chm3-vqcf-52rx

Authentication Bypass

7.1

CVSS 4.0 · Vendor: https://github.com/FlowiseAI/Flowise

Severity by source

Vendor (https://github.com/FlowiseAI/Flowise) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

9.9 CRITICAL

Network-reachable API, PR:L because workspace authentication is required, S:C for cross-workspace boundary violation, A:L for indirect availability impact via OpenAI quota exhaustion.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:H/SI:H/SA:N

Primary rating from Vendor (https://github.com/FlowiseAI/Flowise).

CVSS VectorVendor: https://github.com/FlowiseAI/Flowise

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 04, 2026 - 18:21 vuln.today

Analysis Generated

Aug 04, 2026 - 18:21 vuln.today

CVE Published

Aug 04, 2026 - 17:51 cve.org

HIGH

DescriptionCVE.org

Summary

These endpoints accept a client-controlled credential parameter. The server loads credentials by id and uses them directly, without checking whether that credential belongs to the caller’s workspace. If an attacker knows another workspace’s credentialId, they can use that workspace’s OpenAI key.

Details

Route permissions (assistants:*) only check feature access. They do not check credential ownership. The controller passes req.query.credential straight to the service. The service does findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs. There is no workspaceId check in this flow, so this is an IDOR.

Impact

Cross-workspace unauthorized use of stored OpenAI keys.
Unauthorized read/modify/delete of victim vector stores and files.
Direct billing impact on victim OpenAI account.
Multi-tenant boundary violation with practical exploitability.

Reproduction steps

Set up two workspaces: A (attacker) and B (victim), each with an OpenAI credential.
Log in as a user in workspace A (with assistants-related permissions).
Call /api/v1/openai-assistants-vector-store and set credential to B’s credential ID.
Example: GET /api/v1/openai-assistants-vector-store?credential=<B_credentialId>.
If responses/actions are executed using B’s credential context, the issue is confirmed.

AnalysisAI

Cross-workspace IDOR in Flowise's OpenAI Assistants Vector Store API allows authenticated users of one workspace to access, use, and manipulate another workspace's stored OpenAI credentials. Flowise versions up to and including 3.1.2 pass the client-supplied credential query parameter directly to a database lookup (findOneBy({ id: credentialId })) with no ownership check against the caller's workspaceId, violating the multi-tenant isolation guarantee. An attacker with a valid Flowise account and assistants:* permissions can cause direct financial harm to victim workspaces via unauthorized OpenAI API billing and can read, modify, or delete the victim's vector stores and files. No public exploit code or CISA KEV listing is identified at time of analysis.

Technical ContextAI

Flowise (pkg:npm/flowise) is an open-source low-code platform for building LLM-powered applications; it stores third-party API credentials (e.g., OpenAI keys) per workspace and exposes them through an internal credential service. The affected endpoints - including /api/v1/openai-assistants-vector-store - accept a credential query parameter representing a credential record ID. The route middleware enforces assistants:* permission flags, which verify only that the caller has feature access, not resource ownership. The controller then passes req.query.credential to the service unmodified; the service executes findOneBy({ id: credentialId }) against the credential table without a WHERE workspaceId = ? clause, decrypts the returned credential, and forwards it to the OpenAI API. This is a textbook CWE-285 (Improper Authorization) / Insecure Direct Object Reference (IDOR): authorization enforces the verb (can you use assistants features?) but not the noun (does this credential belong to you?). The fix in commit d81483b adds workspaceId propagation from req.user.activeWorkspaceId into every affected service call, scoping all lookups to the caller's workspace.

RemediationAI

Upgrade Flowise to version 3.1.3 or later; the patch is available at the official release tag https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3 and was introduced via PR #6170 (https://github.com/FlowiseAI/Flowise/pull/6170) and commit d81483b70c997ddf981acc9c49fbd9a02fa345cd. If an immediate upgrade is not possible, restrict the assistants:* permission to only highly-trusted users within each workspace, reducing the pool of accounts that can supply arbitrary credential IDs - note this is a partial mitigation only, as any legitimate assistant user retains the ability to exploit other workspaces. As an additional compensating control, operators can place a reverse proxy or WAF rule that rejects requests where the credential query parameter value does not match a credentialId pattern associated with the authenticated user's workspace, though this requires workspace-to-credential mapping logic external to Flowise. Audit logs should be reviewed for requests to /api/v1/openai-assistants-* endpoints where the credential ID does not belong to the requesting user's workspace.