highCVE-2026-70472Aug 4, 2026

CVE-2026-70472: Flowise Cross-Workspace Credential IDOR in OpenAI Assistants Vector Store

Rohit Hatagale
AI Security Researcher, SecureLayer7

Any authenticated Flowise user with assistant permissions can supply a different workspace's credential ID to the OpenAI assistants vector-store API, letting them read, modify, or delete another…

Packageflowise
Ecosystemnpm
Affected<= 3.1.2
Fixed in3.1.3
CVE-2026-70472: Flowise Cross-Workspace Credential IDOR in OpenAI Assistants Vector Store

The problem

The /api/v1/openai-assistants-vector-store family of endpoints (and related assistant endpoints) accept a client-controlled credential query parameter. The server fetches the credential by ID alone, decrypts it, and forwards it to OpenAI, with no check that the credential belongs to the caller's workspace.

Route-level permission checks only gate on feature access (assistants:*). They do not verify credential ownership. In a multi-tenant deployment this means any authenticated user in any workspace can cross into another workspace's OpenAI key by simply knowing that workspace's credential UUID.

Proof of concept

A working proof-of-concept for CVE-2026-70472 in flowise, with the exact payload below.

http
# Attacker is in Workspace A, victim credential UUID is from Workspace B
# All assistant vector-store actions work against Workspace B's OpenAI key

GET /api/v1/openai-assistants-vector-store?credential=<WORKSPACE_B_CREDENTIAL_ID>
Authorization: Bearer <WORKSPACE_A_JWT>

# List vector stores billed to Workspace B
# Also works for other assistant endpoints:
GET /api/v1/openai-assistants-vector-store/<VECTOR_STORE_ID>/files?credential=<WORKSPACE_B_CREDENTIAL_ID>
DELETE /api/v1/openai-assistants-vector-store/<VECTOR_STORE_ID>?credential=<WORKSPACE_B_CREDENTIAL_ID>

The root cause is a missing ownership check in the credential-loading path (CWE-639 / CWE-285). Before the patch, the service called findOneBy({ id: credentialId }), found any matching credential in the global table, and used it. The fix (commit d81483b, PR #6170, released in 3.1.3) adds a workspace membership check so the lookup becomes effectively findOneBy({ id: credentialId, workspaceId: callerWorkspaceId }), ensuring the credential must belong to the caller's workspace before it is decrypted and used.

This is a textbook IDOR: the object reference (credential UUID) is client-controlled, and authorization was never tied to the actual resource owner. Credential UUIDs are stable and can be inferred from prior API calls or brute-forced, making exploitation straightforward for any authenticated tenant.

The fix

Upgrade Flowise to version 3.1.3 or later. The fix is in commit d81483b70c997ddf981acc9c49fbd9a02fa345cd (PR #6170), which enforces that any credential resolved from a query parameter must belong to the requesting user's workspace before it is decrypted or used.

No configuration change is required beyond upgrading.

Reporter not attributed.

References: [1][2][3][4][5]

Related research