CVE-2026-70475: Flowise missing authz lets users

CISO Take

A missing authorization check on Flowise's execution-update endpoint (PUT /api/v1/executions/:id) lets any authenticated user — regardless of their assigned role or permissions — modify the state, data, and metadata of any workflow execution in their workspace, enabling privilege escalation and falsification of agent execution results. Flowise is a widely deployed low-code builder for LLM agent workflows, so this flaw sits directly in the agent orchestration layer where execution records often double as an audit trail of what an AI agent actually did. While this CVE isn't in CISA KEV, has no public exploit or Nuclei template, and sits at the 78th EPSS percentile with a TRACK_STAR SSVC decision (worth monitoring, not urgent), the bar to exploit is low: it requires only a valid low-privilege account and a direct API call, no AI/ML expertise needed. Given the package's history of 158 other CVEs, treat any Flowise deployment as needing active patch management rather than a one-off fix. Upgrade to Flowise 3.1.3 immediately, and in the interim restrict workspace membership and monitor for anomalous PUT calls to /api/v1/executions/ from low-privilege accounts.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Moderate risk: exploitation requires only a valid authenticated account (any role) within a Flowise workspace — no elevated privileges, no AI/ML expertise, and no victim interaction required. Impact is confined to workspace-scoped execution records (state, data, metadata) rather than full system compromise, but it enables both privilege escalation (acting beyond assigned permissions) and integrity manipulation (falsifying what an agent workflow actually executed or returned). EPSS sits at the 78th percentile (raw score 0.00296) and CISA SSVC rates it TRACK_STAR, with no KEV listing, public exploit, or scanner template observed as of publication. Real-world exposure scales with how broadly workspace membership is granted; multi-tenant or team deployments with loosely managed workspace access are most exposed.

How does the attack unfold?

Initial Access

Attacker obtains or already holds a valid low-privilege authenticated account in a shared Flowise workspace.

AML.T0012

Discovery

Attacker identifies via API inspection that PUT /api/v1/executions/:id lacks the checkAnyPermission() check applied to sibling endpoints.

AML.T0049

Exploitation

Attacker sends a direct PUT request to modify execution state, data, or metadata for an execution ID outside their assigned permissions.

AML.T0081

Impact

Attacker escalates effective privileges and falsifies or disrupts workflow execution results and audit trail integrity for other users in the workspace.

Initial Access

Attacker obtains or already holds a valid low-privilege authenticated account in a shared Flowise workspace.

AML.T0012

Discovery

Attacker identifies via API inspection that PUT /api/v1/executions/:id lacks the checkAnyPermission() check applied to sibling endpoints.

AML.T0049

Exploitation

Attacker sends a direct PUT request to modify execution state, data, or metadata for an execution ID outside their assigned permissions.

AML.T0081

Impact

Attacker escalates effective privileges and falsifies or disrupts workflow execution results and audit trail integrity for other users in the workspace.

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 24% 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

1) Patch: upgrade to Flowise >=3.1.3, which adds the checkAnyPermission() middleware to the PUT /api/v1/executions/:id route (fix in PR #6409, commit 96a9b23). 2) Interim workaround: restrict workspace membership to trusted users only, and where feasible, front the API with a reverse proxy/WAF rule blocking PUT requests to /api/v1/executions/* from roles that shouldn't have execution-write access. 3) Detection: audit API/access logs for PUT /api/v1/executions/:id calls from users without explicit execution-management permissions, and cross-reference execution modification timestamps against expected workflow runs. 4) Post-patch: review execution history for anomalies predating the patch, since this CWE-862 gap could have been exploited silently.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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

How is it classified?

Auth Bypass Agent Framework AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0081 - Modify AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.6.2.3 - AI system operational access control

NIST AI RMF

MANAGE-4.1 - AI risks and benefits are monitored, with mitigation actions taken as needed

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-70475?

A missing authorization check on Flowise's execution-update endpoint (PUT /api/v1/executions/:id) lets any authenticated user — regardless of their assigned role or permissions — modify the state, data, and metadata of any workflow execution in their workspace, enabling privilege escalation and falsification of agent execution results. Flowise is a widely deployed low-code builder for LLM agent workflows, so this flaw sits directly in the agent orchestration layer where execution records often double as an audit trail of what an AI agent actually did. While this CVE isn't in CISA KEV, has no public exploit or Nuclei template, and sits at the 78th EPSS percentile with a TRACK_STAR SSVC decision (worth monitoring, not urgent), the bar to exploit is low: it requires only a valid low-privilege account and a direct API call, no AI/ML expertise needed. Given the package's history of 158 other CVEs, treat any Flowise deployment as needing active patch management rather than a one-off fix. Upgrade to Flowise 3.1.3 immediately, and in the interim restrict workspace membership and monitor for anomalous PUT calls to /api/v1/executions/ from low-privilege accounts.

Is CVE-2026-70475 actively exploited?

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

How to fix CVE-2026-70475?

1) Patch: upgrade to Flowise >=3.1.3, which adds the checkAnyPermission() middleware to the PUT /api/v1/executions/:id route (fix in PR #6409, commit 96a9b23). 2) Interim workaround: restrict workspace membership to trusted users only, and where feasible, front the API with a reverse proxy/WAF rule blocking PUT requests to /api/v1/executions/* from roles that shouldn't have execution-write access. 3) Detection: audit API/access logs for PUT /api/v1/executions/:id calls from users without explicit execution-management permissions, and cross-reference execution modification timestamps against expected workflow runs. 4) Post-patch: review execution history for anomalies predating the patch, since this CWE-862 gap could have been exploited silently.

What systems are affected by CVE-2026-70475?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration, RAG pipelines.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestrationRAG pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM06:2025

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, the PUT /api/v1/executions/:id endpoint in packages/server/src/routes/executions/index.ts lacks the checkAnyPermission() middleware that protects other execution endpoints. Any authenticated user, regardless of assigned permissions, can modify execution state, data, and metadata of any execution in their workspace, enabling privilege escalation and manipulation of workflow execution results. This issue is fixed in 3.1.3.

Exploitation Scenario

An attacker who has obtained (or been granted) a low-privilege authenticated account in a shared Flowise workspace — e.g., a contractor or team member without execution-management rights — discovers via API inspection that PUT /api/v1/executions/:id has no permission check, unlike its sibling endpoints. They call the endpoint directly against execution IDs belonging to other users in the workspace, rewriting execution state and metadata to mask a malicious agent run, forge a 'successful' result for a compliance-relevant workflow, or disrupt a colleague's in-progress agent execution — all without needing the UI-gated permissions that would normally block such actions.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization Primary CWE-862 Missing 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.