CVE-2026-91929: Flowise cross-tenant authorization

CISO Take

Flowise versions before 3.1.4 fail to check resource ownership in several Enterprise endpoints (CWE-862), so an authenticated tenant can delete other organizations' workspaces, invite themselves into other organizations, change cross-org roles and abuse stored SSO secrets. This breaks tenant isolation on shared or multi-tenant Flowise deployments that host AI agent workflows, and the SSO secret exposure could extend the damage into the corporate identity layer. Near-term exploitation risk is moderate to low: EPSS is 0.00352 (top 73%), the flaw is not in CISA KEV, no public exploit or Nuclei template exists, CISA SSVC says TRACK, and exploitation needs a valid low-privilege Enterprise account and high attack complexity. Upgrade to Flowise 3.1.4 or later, rotate any SSO secrets configured in affected instances, and review audit logs for unexpected workspace deletions, invitations and role changes.

Sources:NVDEPSSGitHub AdvisoryVulnCheckATLAS

What is the risk?

High severity (CVSS 7.1) but moderated by high attack complexity and the need for low-privilege authenticated access. Confidentiality and integrity impact are high because of cross-tenant access and SSO secret abuse, and availability impact is low because workspaces can be deleted. Exploitation likelihood is currently modest (EPSS 0.35%, no KEV listing, no public exploit). Exposure is greatest for multi-tenant or SaaS-style Flowise Enterprise deployments, and for hosts where any customer or employee can obtain an account.

How does the attack unfold?

Initial Access

Attacker authenticates with a low-privilege Enterprise account on the Flowise instance.

AML.T0012

Exploitation

Attacker calls Enterprise endpoints with other tenants' resource IDs, and the missing ownership checks let the calls succeed.

AML.T0049

Privilege Escalation

Attacker invites themselves into other organizations and modifies cross-org roles to gain access to their agents and credentials.

Impact

Attacker deletes workspaces, abuses stored SSO secrets and accesses other tenants' agent flows and data.

AML.T0101

Initial Access

Attacker authenticates with a low-privilege Enterprise account on the Flowise instance.

AML.T0012

Exploitation

Attacker calls Enterprise endpoints with other tenants' resource IDs, and the missing ownership checks let the calls succeed.

AML.T0049

Privilege Escalation

Attacker invites themselves into other organizations and modifies cross-org roles to gain access to their agents and credentials.

Impact

Attacker deletes workspaces, abuses stored SSO secrets and accesses other tenants' agent flows and data.

AML.T0101

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.1 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 29% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACHigh

PRLow

UINone

SUnchanged

CHigh

IHigh

ALow

What should I do?

1 step

1) Upgrade Flowise to 3.1.4 or later. 2) Rotate SSO client secrets and any credentials or API keys stored in affected workspaces if cross-tenant access cannot be ruled out. 3) Until patched, restrict Enterprise endpoint access to trusted users, put the admin and Enterprise APIs behind a VPN or IP allowlist, and limit account creation. 4) Review audit and application logs for workspace deletions, unexpected organization invitations, cross-org role changes and access to SSO configuration endpoints. 5) Restore any deleted workspaces from backups and verify that role assignments match what you expect. 6) Check the GHSA-7x8x-vv46-4579 and VulnCheck advisories for updates.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impacttotal

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassData LeakageFrameworkAgentAPIAML.T0012- Valid Accounts AML.T0049- Exploit Public-Facing Application AML.T0101- Data Destruction via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks and incidents

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-91929?

Flowise versions before 3.1.4 fail to check resource ownership in several Enterprise endpoints (CWE-862), so an authenticated tenant can delete other organizations' workspaces, invite themselves into other organizations, change cross-org roles and abuse stored SSO secrets. This breaks tenant isolation on shared or multi-tenant Flowise deployments that host AI agent workflows, and the SSO secret exposure could extend the damage into the corporate identity layer. Near-term exploitation risk is moderate to low: EPSS is 0.00352 (top 73%), the flaw is not in CISA KEV, no public exploit or Nuclei template exists, CISA SSVC says TRACK, and exploitation needs a valid low-privilege Enterprise account and high attack complexity. Upgrade to Flowise 3.1.4 or later, rotate any SSO secrets configured in affected instances, and review audit logs for unexpected workspace deletions, invitations and role changes.

Is CVE-2026-91929 actively exploited?

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

How to fix CVE-2026-91929?

1) Upgrade Flowise to 3.1.4 or later. 2) Rotate SSO client secrets and any credentials or API keys stored in affected workspaces if cross-tenant access cannot be ruled out. 3) Until patched, restrict Enterprise endpoint access to trusted users, put the admin and Enterprise APIs behind a VPN or IP allowlist, and limit account creation. 4) Review audit and application logs for workspace deletions, unexpected organization invitations, cross-org role changes and access to SSO configuration endpoints. 5) Restore any deleted workspaces from backups and verify that role assignments match what you expect. 6) Check the GHSA-7x8x-vv46-4579 and VulnCheck advisories for updates.

What systems are affected by CVE-2026-91929?

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

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

CVE-2026-91929 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.35%.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM workflow orchestrationmulti-tenant AI platformsSSO-integrated AI applications

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0049Exploit Public-Facing Application

AML.T0101Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Flowise versions before 3.1.4 contain cross-tenant authorization gaps in Enterprise endpoints that fail to verify resource ownership before operations. Attackers with Enterprise access can delete arbitrary workspaces, invite themselves into other organizations, modify cross-org roles, and abuse stored SSO secrets.

Exploitation Scenario

An attacker obtains a low-privilege account on a multi-tenant Flowise Enterprise instance, for example through a trial signup or a compromised employee account. They enumerate workspace and organization identifiers and call Enterprise endpoints that do not verify resource ownership. They invite themselves into a competitor's or customer's organization, raise their role and read agent flows, credentials and SSO secrets. They then use the SSO secrets to attempt identity impersonation, or delete the victim's workspaces to cause disruption.

Weaknesses (CWE)

CWE-862Missing AuthorizationPrimary CWE-862Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[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.