CVE-2026-56268: Flowise: cross-workspace chatflow config disclosure

HIGH
Published June 22, 2026
CISO Take

Any authenticated Flowise user holding a valid API key for their own workspace can retrieve the complete configuration—system prompts, node graphs, API settings, and credential IDs—of every chatflow across all other workspaces on the same instance that lack an assigned API key, by simply omitting the `keyonly` query parameter from a single GET request to `/api/v1/chatflows/apikey/<key>`. With 96 prior CVEs in the Flowise package, this platform has a well-documented history as a high-value target, and the trivially low attack complexity (no special tooling, no reverse engineering) means any trial account on a shared instance is a viable insider threat vector. The CVSS 7.7 Changed-scope score reflects true multi-tenant blast radius: a single compromised or purchased API key puts every unprotected workspace's proprietary AI agent logic and connected credentials at risk. Upgrade to Flowise 3.1.2 immediately; as a stopgap, assign an explicit API key to every chatflow in every workspace and audit HTTP access logs for requests to the affected endpoint that omit the `keyonly` parameter.

Sources: NVD GitHub Advisory ATLAS VulnCheck

What is the risk?

High risk for any multi-tenant Flowise deployment. Exploitation requires nothing beyond a valid API key—a trivially low bar achievable via a free trial or shared-instance account—and the attack vector is a single unauthenticated query parameter omission, requiring zero AI/ML expertise. The exposed data is disproportionately sensitive for AI deployments: system prompts represent proprietary intellectual property, and credential IDs may serve as pivot points into integrated LLM APIs, databases, and external tooling. No public exploit code has been confirmed, but weaponization time is near-zero given advisory publication—the attack surface is fully described in the advisory and requires no exploitation framework.

How does the attack unfold?

Initial Access
Attacker obtains a valid Flowise API key for any workspace on the target instance, requiring only a legitimate account (trial or paid) on a shared deployment.
AML.T0012
Authorization Bypass
Attacker sends GET /api/v1/chatflows/apikey/<key> without the keyonly query parameter, triggering the unscoped database query that returns results across all workspaces.
AML.T0049
Configuration Exfiltration
Server returns full chatflow configurations—including system prompts, node graphs, apiConfig, and credential IDs—for all unprotected chatflows across every foreign workspace.
AML.T0084
Impact
Attacker extracts proprietary system prompts (IP theft), enumerates credential IDs for pivot into connected services, and maps victim agent architectures for targeted follow-on attacks.
AML.T0056

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Flowise npm No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1
7.7 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Changed
C High
I None
A None

What should I do?

5 steps
  1. Patch immediately: upgrade all Flowise instances to version 3.1.2 which introduces workspace-scoped filtering in the chatflow API key query.

  2. Temporary workaround (pre-patch): assign an explicit API key to every chatflow in every workspace—the vulnerability only exposes chatflows where the API key field is empty.

  3. Detection: audit HTTP access logs for GET requests to /api/v1/chatflows/apikey/ where the keyonly query parameter is absent; flag and investigate all such requests on unpatched instances as potential reconnaissance.

  4. Post-incident: treat all credential IDs referenced in any chatflow as potentially compromised and rotate them, particularly for LLM API keys and database credentials embedded in chatflow configurations.

  5. Architecture review: evaluate whether high-sensitivity workspaces require dedicated Flowise instances rather than shared multi-tenant deployments to enforce hard network-level isolation.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 9 - Risk management system
ISO 42001
A.6.2.4 - AI system access control
NIST AI RMF
GOVERN 6.2 - Policies and procedures are in place for AI risk management
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-56268?

Any authenticated Flowise user holding a valid API key for their own workspace can retrieve the complete configuration—system prompts, node graphs, API settings, and credential IDs—of every chatflow across all other workspaces on the same instance that lack an assigned API key, by simply omitting the `keyonly` query parameter from a single GET request to `/api/v1/chatflows/apikey/<key>`. With 96 prior CVEs in the Flowise package, this platform has a well-documented history as a high-value target, and the trivially low attack complexity (no special tooling, no reverse engineering) means any trial account on a shared instance is a viable insider threat vector. The CVSS 7.7 Changed-scope score reflects true multi-tenant blast radius: a single compromised or purchased API key puts every unprotected workspace's proprietary AI agent logic and connected credentials at risk. Upgrade to Flowise 3.1.2 immediately; as a stopgap, assign an explicit API key to every chatflow in every workspace and audit HTTP access logs for requests to the affected endpoint that omit the `keyonly` parameter.

Is CVE-2026-56268 actively exploited?

No confirmed active exploitation of CVE-2026-56268 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-56268?

1. Patch immediately: upgrade all Flowise instances to version 3.1.2 which introduces workspace-scoped filtering in the chatflow API key query. 2. Temporary workaround (pre-patch): assign an explicit API key to every chatflow in every workspace—the vulnerability only exposes chatflows where the API key field is empty. 3. Detection: audit HTTP access logs for GET requests to `/api/v1/chatflows/apikey/` where the `keyonly` query parameter is absent; flag and investigate all such requests on unpatched instances as potential reconnaissance. 4. Post-incident: treat all credential IDs referenced in any chatflow as potentially compromised and rotate them, particularly for LLM API keys and database credentials embedded in chatflow configurations. 5. Architecture review: evaluate whether high-sensitivity workspaces require dedicated Flowise instances rather than shared multi-tenant deployments to enforce hard network-level isolation.

What systems are affected by CVE-2026-56268?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI platforms, LLM workflow orchestration, AI chatbot deployments.

What is the CVSS score for CVE-2026-56268?

CVE-2026-56268 has a CVSS v3.1 base score of 7.7 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant AI platformsLLM workflow orchestrationAI chatbot deployments

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0056 Extract LLM System Prompt
AML.T0083 Credentials from AI Agent Configuration
AML.T0084 Discover AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 9
ISO 42001: A.6.2.4
NIST AI RMF: GOVERN 6.2
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Flowise before 3.1.2 contains an information disclosure vulnerability in the /api/v1/chatflows/apikey/:apikey endpoint. When the keyonly query parameter is omitted (the default), the endpoint returns not only the chatflows bound to the supplied API key but also all chatflows across every workspace that have no API key assigned, because the underlying query lacks any workspace filter. An attacker with a valid API key for one workspace can therefore retrieve the full ChatFlow configuration (including flowData with system prompts and node configurations, chatbotConfig, apiConfig, and credential IDs) of unprotected chatflows belonging to other workspaces.

Exploitation Scenario

An adversary registers a low-cost or trial account on a multi-tenant Flowise SaaS deployment, obtaining a valid API key for their isolated workspace. They issue a single HTTP GET to `/api/v1/chatflows/apikey/<their_key>` without appending `?keyonly=true`. The unpatched backend executes a database query that returns all chatflows across all workspaces lacking an assigned API key—not just the attacker's own. The JSON response contains full flowData (system prompt text, LangChain node configurations, tool integrations), chatbotConfig, and credential ID references for potentially dozens of foreign workspaces. The attacker systematically extracts proprietary system prompts from competitor organizations' AI products, catalogs credential IDs to attempt downstream pivot into connected LLM APIs or databases, and maps the agent architecture of victim organizations to inform targeted follow-on attacks. The entire operation requires no special tooling—a curl command suffices.

Weaknesses (CWE)

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
June 22, 2026
Last Modified
June 22, 2026
First Seen
June 23, 2026

Related Vulnerabilities