EUVD-2026-52794
GHSA-p5w8-m249-4r4v
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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
PR:L because valid workspace credentials are required; VA:H because targeted flows are irreversibly deleted; no confidentiality or integrity impact applies.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, DELETE /api/v1/chatflows/:id authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3.
AnalysisAI
Flowise's DELETE /api/v1/chatflows/:id endpoint fails to enforce RBAC boundaries between flow resource types, allowing authenticated workspace members to delete flows they are not permitted to manage. Users holding only agentflows:delete can permanently destroy CHATFLOW resources, and users holding only chatflows:delete can destroy AGENTFLOW resources, in the same workspace. All Flowise installations prior to 3.1.3 are affected; no public standalone exploit tool exists, but the GHSA advisory (GHSA-p5w8-m249-4r4v) supplies a verbatim curl reproduction demonstrating the issue with minimal effort.
Technical ContextAI
Flowise is an open-source, LangChain-based visual builder for LLM workflows distributed as an npm package (flowise, CPE: cpe:2.3:a:flowiseai:flowise:*:*:*:*:*:*:*:*). The DELETE route at /api/v1/chatflows/:id applies a logical OR permission gate - checkAnyPermission('chatflows:delete,agentflows:delete') - meaning possession of either permission clears the authorization check regardless of the target's actual resource type. The underlying service function deleteChatflow() then resolves the target record only by id and workspaceId and deletes it without inspecting the record's .type field (CHATFLOW, AGENTFLOW, MULTIAGENT, or ASSISTANT). This is a textbook CWE-863 (Incorrect Authorization) failure: the system checks whether the subject holds *a* delete permission but never verifies that the permission domain matches the object being acted upon, breaking the intended RBAC separation between Chatflow and Agentflow administrators. The fix in PR #6445 builds a userPermittedTypes list from the caller's actual permission set before calling the service, and the service then rejects deletions where the target type is not in that list.
RemediationAI
Upgrade to Flowise 3.1.3 (https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3), which is the vendor-confirmed fix as documented in GHSA-p5w8-m249-4r4v and implemented in commit 2f528ceced74afaa95fc7a282965e7788796448b via PR #6445. The patch introduces per-permission-type validation in the delete controller - chatflows:delete is now bound exclusively to CHATFLOW-type records, agentflows:delete to AGENTFLOW and MULTIAGENT types, and assistants:delete to ASSISTANT types. If immediate upgrade is not feasible, the most effective compensating control is to restrict workspace user roles so that no account holds only a partial delete permission - either grant full administrative rights (which already bypasses the flaw safely) or revoke all delete permissions from accounts that do not require them. Auditing existing API keys for agentflows:delete or chatflows:delete grants and rotating or scoping them reduces the attack surface. There is no documented configuration toggle or network-layer workaround that fully closes the authorization gap without the code fix; these mitigations reduce the population of potential abusers but do not eliminate the vulnerability for accounts that legitimately hold one of the affected permissions.
Flowise version 3.0.5 contains a remote code execution vulnerability in the CustomMCP node. The mcpServerConfig paramete
Flowise versions before 3.0.1 allow unauthenticated access to the Custom MCPs feature, which is designed to execute OS c
FlowiseAI Flowise version 2.2.6 contains an arbitrary file upload vulnerability in the /api/v1/attachments endpoint. Una
Remote code execution in Flowise before 3.1.2 allows any authenticated user (or API caller with chatflow view/update per
Flowise is a drag & drop user interface to build a customized large language model flow. Rated critical severity (CVSS 9
Unrestricted file upload in Flowise LLM workflow builder before 3.0.13 via /api/v1/attachments endpoint allows unauthent
Missing authentication on NVD data endpoint in Flowise before 3.0.13 allows unauthenticated access to internal vulnerabi
Remote code execution in Flowise before 3.1.3 arises because its Pyodide Python-code validator (validatePythonCodeForDat
Remote code execution in FlowiseAI Flowise before 3.1.3 lets an attacker execute arbitrary OS commands as the Flowise pr
Remote command execution in Flowise <= 3.1.2 lets an authenticated user break out of the vm2/@flowiseai/nodevm JavaScrip
Arbitrary file read and write in FlowiseAI Flowise (versions 2.2.8 through 3.0.5) lets remote unauthenticated attackers
Authenticated remote code execution in FlowiseAI Flowise prior to 3.1.2 allows any user with a valid session or API key
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today