CVE-2026-70472: Flowise broken auth exposes

Q: Is CVE-2026-70472 actively exploited?

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

Q: How to fix CVE-2026-70472?

1) Upgrade to Flowise 3.1.3 or later immediately — this closes the missing workspaceId check. 2) Rotate all OpenAI API keys stored as Flowise credentials post-patch, since any credentialId exposure prior to patching should be treated as a potential key compromise. 3) Scope OpenAI keys to per-project/per-workspace with spend caps and usage alerts so a misuse event is capped and detected quickly. 4) Audit Flowise access/application logs for calls to assistants:*/openai-assistants-vector-store endpoints carrying a credential query parameter that doesn't match the caller's own workspace. 5) Review OpenAI account billing/usage dashboards for anomalous vector-store operations from unfamiliar file/store IDs as a compromise indicator.

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

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

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

No CVSS score has been assigned yet.

CISO Take

Flowise's OpenAI Assistants vector-store endpoints trust a client-supplied credential ID without checking that it actually belongs to the caller's workspace, so any authenticated user who obtains another tenant's credential ID can silently borrow that tenant's OpenAI API key to read, modify, or delete their vector stores and files. This is a textbook multi-tenant isolation failure (CWE-285/CWE-863) in an agent framework that already carries 158 other tracked CVEs, and while EPSS sits at a low absolute 0.00246 (top 84th percentile relative to other CVEs, not a high real-world probability) with no public PoC, Nuclei template, or CISA KEV listing, CISA's SSVC decision of Track* still flags it for monitoring given the direct billing-fraud and data-exfiltration impact on victim OpenAI accounts. Any multi-tenant Flowise deployment — self-hosted or cloud — where workspace users don't fully trust each other is exposed, since the flaw lives in the shared assistants/vector-store routes rather than a per-tenant misconfiguration. Patch to Flowise 3.1.3 immediately; until then, rotate OpenAI keys stored as Flowise credentials, restrict access to assistants:* routes, and review OpenAI usage/billing logs for vector-store activity from unexpected credential IDs.

Sources: NVD GitHub Advisory EPSS ATLAS CISA SSVC

What is the risk?

High severity despite modest EPSS and no known exploitation: the vulnerability requires only an authenticated Flowise session plus knowledge of another workspace's credentialId, which is not publicly guessable but can leak via logs, support tickets, shared screenshots, URLs, or chained IDOR elsewhere in the platform. Once obtained, the attacker gets full use of the victim's decrypted OpenAI key server-side — no additional exploitation skill needed, since the vulnerable code path (findOneBy on credential id, decrypt, call OpenAI) does the work for the attacker. Impact spans confidentiality (read victim vector stores/files), integrity (modify/delete them), and availability/financial (unbounded OpenAI billing on the victim's account). Exposure is concentrated in multi-tenant Flowise instances — the more workspaces/users on a shared deployment, the larger the attack surface for credentialId discovery.

How does the attack unfold?

Credential ID discovery

Attacker obtains another workspace's credentialId through leakage, guessing, or a chained enumeration flaw.

AML.T0055

Unauthorized endpoint call

Attacker calls the openai-assistants-vector-store endpoint passing the victim's credentialId; the route only checks generic assistants:* feature access, not workspace ownership.

AML.T0049

Credential decryption and misuse

The service loads and decrypts the victim's OpenAI key server-side and issues API calls on the attacker's behalf.

AML.T0091.000

Data and billing impact

Attacker reads, modifies, or deletes the victim's vector stores/files and drives up OpenAI billing charged to the victim account.

AML.T0034

Credential ID discovery

Attacker obtains another workspace's credentialId through leakage, guessing, or a chained enumeration flaw.

AML.T0055

Unauthorized endpoint call

Attacker calls the openai-assistants-vector-store endpoint passing the victim's credentialId; the route only checks generic assistants:* feature access, not workspace ownership.

AML.T0049

Credential decryption and misuse

The service loads and decrypts the victim's OpenAI key server-side and issues API calls on the attacker's behalf.

AML.T0091.000

Data and billing impact

Attacker reads, modifies, or deletes the victim's vector stores/files and drives up OpenAI billing charged to the victim account.

AML.T0034

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 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

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) Upgrade to Flowise 3.1.3 or later immediately — this closes the missing workspaceId check. 2) Rotate all OpenAI API keys stored as Flowise credentials post-patch, since any credentialId exposure prior to patching should be treated as a potential key compromise. 3) Scope OpenAI keys to per-project/per-workspace with spend caps and usage alerts so a misuse event is capped and detected quickly. 4) Audit Flowise access/application logs for calls to assistants:*/openai-assistants-vector-store endpoints carrying a credential query parameter that doesn't match the caller's own workspace. 5) Review OpenAI account billing/usage dashboards for anomalous vector-store operations from unfamiliar file/store IDs as a compromise indicator.

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 Data Leakage Agent RAG API AML.T0034 - Cost Harvesting AML.T0049 - Exploit Public-Facing Application AML.T0085.000 - RAG Databases AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6.2 - AI system access control

OWASP LLM Top 10

LLM08:2025 - Vector and Embedding Weaknesses LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-70472?

Flowise's OpenAI Assistants vector-store endpoints trust a client-supplied credential ID without checking that it actually belongs to the caller's workspace, so any authenticated user who obtains another tenant's credential ID can silently borrow that tenant's OpenAI API key to read, modify, or delete their vector stores and files. This is a textbook multi-tenant isolation failure (CWE-285/CWE-863) in an agent framework that already carries 158 other tracked CVEs, and while EPSS sits at a low absolute 0.00246 (top 84th percentile relative to other CVEs, not a high real-world probability) with no public PoC, Nuclei template, or CISA KEV listing, CISA's SSVC decision of Track* still flags it for monitoring given the direct billing-fraud and data-exfiltration impact on victim OpenAI accounts. Any multi-tenant Flowise deployment — self-hosted or cloud — where workspace users don't fully trust each other is exposed, since the flaw lives in the shared assistants/vector-store routes rather than a per-tenant misconfiguration. Patch to Flowise 3.1.3 immediately; until then, rotate OpenAI keys stored as Flowise credentials, restrict access to assistants:* routes, and review OpenAI usage/billing logs for vector-store activity from unexpected credential IDs.

Is CVE-2026-70472 actively exploited?

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

How to fix CVE-2026-70472?

1) Upgrade to Flowise 3.1.3 or later immediately — this closes the missing workspaceId check. 2) Rotate all OpenAI API keys stored as Flowise credentials post-patch, since any credentialId exposure prior to patching should be treated as a potential key compromise. 3) Scope OpenAI keys to per-project/per-workspace with spend caps and usage alerts so a misuse event is capped and detected quickly. 4) Audit Flowise access/application logs for calls to assistants:*/openai-assistants-vector-store endpoints carrying a credential query parameter that doesn't match the caller's own workspace. 5) Review OpenAI account billing/usage dashboards for anomalous vector-store operations from unfamiliar file/store IDs as a compromise indicator.

What systems are affected by CVE-2026-70472?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesagent frameworksvector databases

MITRE ATLAS Techniques

AML.T0034 Cost Harvesting

AML.T0049 Exploit Public-Facing Application

AML.T0085.000 RAG Databases

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6.2

OWASP LLM Top 10: LLM08:2025, LLM10: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, Flowise openai-assistants-vector-store endpoints accept a client-controlled credential parameter and load credentials by id without checking whether that credential belongs to the caller workspace. Route permissions assistants:* only check feature access. The controller passes req.query.credential straight to the service, and the service uses findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs without a workspaceId check. If an attacker knows another workspace credentialId, the attacker can use that workspace OpenAI key, read, modify, or delete victim vector stores and files, cause billing impact on the victim OpenAI account, and violate multi-tenant boundaries. This issue is fixed in version 3.1.3.

Exploitation Scenario

An attacker with a low-privilege authenticated account on a shared/multi-tenant Flowise instance obtains another workspace's credentialId — for example via a leaked support screenshot, a shared debugging URL, or an unrelated IDOR that enumerates credential records. They then call the openai-assistants-vector-store endpoint, passing that credentialId as req.query.credential. Because the route only checks that the caller has generic assistants:* feature access (not workspace ownership of the specific credential), Flowise's service layer loads and decrypts the victim's OpenAI key server-side and issues API calls on the attacker's behalf. The attacker can now enumerate, read, or delete the victim's vector stores and files, and every call is billed to the victim's OpenAI account — enabling data theft, service disruption, and cost-harvesting fraud without ever touching the victim's actual OpenAI credentials directly.

Weaknesses (CWE)

CWE-285 Improper Authorization Primary CWE-285 Improper Authorization Primary CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization Primary CWE-285 Improper Authorization CWE-863 Incorrect Authorization

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs 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) 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 you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply 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.

Source: MITRE CWE corpus.