CVE-2026-69262: Flowise broken authz

Q: Is CVE-2026-69262 actively exploited?

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

Q: How to fix CVE-2026-69262?

Upgrade Flowise to version 3.1.3 or later, where the delete endpoint validates that the caller's permission matches the actual resource type being deleted (fix: github.com/FlowiseAI/Flowise/commit/2f528ce). Until patched, treat chatflows:delete and agentflows:delete as functionally equivalent when assigning roles — do not rely on this split to enforce separation of duties between teams. Review current workspace role assignments and revoke either delete permission from users who should not be able to delete both chatflow and agentflow resources. Enable and monitor audit logging on DELETE /api/v1/chatflows/:id and DELETE /api/v1/agentflows/:id, flagging any deletion performed by an account that only holds the opposite-type permission. Maintain workflow backups/version history outside Flowise so accidental or malicious deletions are recoverable.

Q: What systems are affected by CVE-2026-69262?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code/no-code LLM orchestration.

Q: What is the CVSS score for CVE-2026-69262?

No CVSS score has been assigned yet.

CISO Take

Flowise, prior to version 3.1.3, checked delete requests against either of two separate permissions (chatflows:delete or agentflows:delete) without verifying that the permission matched the actual resource type being deleted, so a user holding only agentflows:delete could destroy a chatflow, and vice versa, within the same workspace. This matters for any team using Flowise's role-based access as a real security boundary between teams building chatflows and teams building agentflows: a low-privilege or partially-scoped user can silently destroy another team's production AI workflow with a single API call, which is a data-integrity and availability problem, not just a permissions nuisance. There is no known public exploit or scanner template, EPSS sits at 0.00246 (top 84th percentile relative to other CVEs, but still a low absolute probability), and it is not in CISA KEV, so this looks like low-noise but real internal-threat exposure rather than an actively hunted bug. The fix is straightforward: upgrade to Flowise 3.1.3 or later, and in the interim audit which users hold chatflows:delete or agentflows:delete and treat both permissions as equivalent to 'can delete any flow in the workspace' until patched. Detection: review audit logs for DELETE calls on /api/v1/chatflows/:id or /api/v1/agentflows/:id from accounts that should only have one of the two delete scopes.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

Rated high severity due to the authorization logic flaw (CWE-863) allowing privilege confusion between two distinct resource types. Exploitability is low-complexity (a single authenticated DELETE request with an existing but mismatched permission) but requires the attacker to already hold valid Flowise credentials with at least one delete-type permission in the target workspace, which limits this to insider threats, compromised low-privilege accounts, or over-permissioned collaborators rather than unauthenticated internet-wide attackers. No public exploit code or Nuclei template exists, and CISA SSVC classifies it TRACK_STAR (track with priority, no urgent action mandated), consistent with a real but non-actively-exploited flaw. The main risk driver is impact: irreversible deletion of production AI workflows (chatflows or agentflows) by users who should not have that authority, which is a data-loss and business-continuity issue in any team running customer-facing or automated LLM pipelines through Flowise.

How does the attack unfold?

Authenticated foothold

Attacker holds or compromises a Flowise workspace account with only one of the two delete permissions (chatflows:delete or agentflows:delete).

AML.T0012

Authorization bypass

Attacker sends a DELETE request to the opposite resource type's endpoint; the handler accepts it because it only checks for possession of either delete permission, not that it matches the target's actual type.

AML.T0081

Destructive impact

The unauthorized chatflow or agentflow is permanently deleted, disrupting the AI workflow it powered and potentially causing data loss and service outage for downstream users.

Authenticated foothold

Attacker holds or compromises a Flowise workspace account with only one of the two delete permissions (chatflows:delete or agentflows:delete).

AML.T0012

Authorization bypass

Attacker sends a DELETE request to the opposite resource type's endpoint; the handler accepts it because it only checks for possession of either delete permission, not that it matches the target's actual type.

AML.T0081

Destructive impact

The unauthorized chatflow or agentflow is permanently deleted, disrupting the AI workflow it powered and potentially causing data loss and service outage for downstream users.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	<= 3.1.2	`3.1.3`

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step

Upgrade Flowise to version 3.1.3 or later, where the delete endpoint validates that the caller's permission matches the actual resource type being deleted (fix: github.com/FlowiseAI/Flowise/commit/2f528ce). Until patched, treat chatflows:delete and agentflows:delete as functionally equivalent when assigning roles — do not rely on this split to enforce separation of duties between teams. Review current workspace role assignments and revoke either delete permission from users who should not be able to delete both chatflow and agentflow resources. Enable and monitor audit logging on DELETE /api/v1/chatflows/:id and DELETE /api/v1/agentflows/:id, flagging any deletion performed by an account that only holds the opposite-type permission. Maintain workflow backups/version history outside Flowise so accidental or malicious deletions are recoverable.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable Yes

Technical Impact partial

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

How is it classified?

Auth Bypass DoS Agent Framework AML.T0081 - Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

8.1 - Operational planning and control

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-69262?

Flowise, prior to version 3.1.3, checked delete requests against either of two separate permissions (chatflows:delete or agentflows:delete) without verifying that the permission matched the actual resource type being deleted, so a user holding only agentflows:delete could destroy a chatflow, and vice versa, within the same workspace. This matters for any team using Flowise's role-based access as a real security boundary between teams building chatflows and teams building agentflows: a low-privilege or partially-scoped user can silently destroy another team's production AI workflow with a single API call, which is a data-integrity and availability problem, not just a permissions nuisance. There is no known public exploit or scanner template, EPSS sits at 0.00246 (top 84th percentile relative to other CVEs, but still a low absolute probability), and it is not in CISA KEV, so this looks like low-noise but real internal-threat exposure rather than an actively hunted bug. The fix is straightforward: upgrade to Flowise 3.1.3 or later, and in the interim audit which users hold chatflows:delete or agentflows:delete and treat both permissions as equivalent to 'can delete any flow in the workspace' until patched. Detection: review audit logs for DELETE calls on /api/v1/chatflows/:id or /api/v1/agentflows/:id from accounts that should only have one of the two delete scopes.

Is CVE-2026-69262 actively exploited?

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

How to fix CVE-2026-69262?

Upgrade Flowise to version 3.1.3 or later, where the delete endpoint validates that the caller's permission matches the actual resource type being deleted (fix: github.com/FlowiseAI/Flowise/commit/2f528ce). Until patched, treat chatflows:delete and agentflows:delete as functionally equivalent when assigning roles — do not rely on this split to enforce separation of duties between teams. Review current workspace role assignments and revoke either delete permission from users who should not be able to delete both chatflow and agentflow resources. Enable and monitor audit logging on DELETE /api/v1/chatflows/:id and DELETE /api/v1/agentflows/:id, flagging any deletion performed by an account that only holds the opposite-type permission. Maintain workflow backups/version history outside Flowise so accidental or malicious deletions are recoverable.

What systems are affected by CVE-2026-69262?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code/no-code LLM orchestration.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworkslow-code/no-code LLM orchestration

MITRE ATLAS Techniques

AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: 8.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

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.

Exploitation Scenario

A contractor or team member is granted agentflows:delete so they can clean up test agent workflows, but has no chatflows:delete permission and should have no ability to touch the customer-support chatflow another team maintains. That user (or their compromised account) sends a DELETE request to /api/v1/chatflows/:id for the production chatflow's id within the shared workspace. Because Flowise's authorization check only confirms the caller holds *some* delete permission (checkAnyPermission on chatflows:delete OR agentflows:delete) and the delete logic never re-validates that the target id is actually an agentflow, the request succeeds and the production chatflow is deleted — taking down a live customer-facing AI workflow with no permission violation ever being flagged.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization

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.