CVE-2026-67622: Flowise: IDOR in Assistants API leaks OpenAI credentials

CRITICAL CISA: ATTEND
Published August 6, 2026
CISO Take

A missing workspace-scoped authorization check in Flowise's OpenAI Assistants integration lets any authenticated user swap in another workspace's credential UUID and retrieve that workspace's OpenAI API credentials, along with cross-workspace assistant metadata and file/vector store listings — and even upload files into a victim's workspace. This is a 9.9 CVSS critical: with low privileges required, no user interaction, and network access, any tenant on a shared Flowise deployment can pivot laterally to every other tenant's OpenAI credentials, opening a direct path to API cost abuse, RAG data exposure, and file/prompt tampering. The EPSS score (0.25%, ~84th percentile) and absence from CISA KEV suggest exploitation isn't yet automated at scale, and CISA's SSVC verdict is only ATTEND — but no public PoC or Nuclei template today doesn't mean one won't appear soon, especially since the vendor reference points to flowiseai.com/sunset, suggesting Flowise itself may be winding down rather than shipping a fix. Any organization running multi-tenant or shared Flowise instances up to 3.1.4 should immediately audit workspace isolation, rotate every OpenAI credential stored in Flowise, and treat this as a forcing function to evaluate migrating off an apparently sunsetting product.

Sources: NVD EPSS CISA SSVC ATLAS vulncheck.com flowiseai.com

What is the risk?

Critical (CVSS 9.9) primarily because privileges required are low, user interaction is none, and the attack is trivially repeatable by enumerating UUIDs — no exploitation sophistication is needed beyond an authenticated session on the target instance. Confidentiality and integrity impact are both high (credential and metadata disclosure, unauthorized file uploads into a victim workspace), while availability impact is low. EPSS sits at 0.25% (~84th percentile) and there's no CISA KEV listing, public exploit, or Nuclei template, so this isn't yet under mass exploitation — but the trivial exploitation mechanics (swap a UUID in an API call) mean a working exploit could surface quickly from the already-published technical write-up. Real-world exposure scales directly with how many organizations run Flowise as a shared, multi-tenant service versus fully isolated single-tenant deployments.

How does the attack unfold?

Initial Access
Attacker obtains a low-privilege, authenticated account on a shared/multi-tenant Flowise instance.
AML.T0012
Enumeration
Attacker supplies arbitrary credential UUIDs to Assistants endpoints to discover other workspaces' assistant metadata, files, and vector stores.
AML.T0084
Credential Access
Missing workspace-ownership checks return the victim workspace's OpenAI API credentials to the attacker.
AML.T0055
Impact
Attacker exfiltrates data via the stolen OpenAI credential or uploads malicious files into the victim workspace, poisoning downstream RAG retrieval.
AML.T0025

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
9.9 / 10
EPSS
0.3%
chance of exploitation in 30 days
Higher than 26% of all CVEs
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 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 High
A Low

What should I do?

1 step
  1. No patched version is listed by the vendor, and the referenced advisory (flowiseai.com/sunset) suggests Flowise may not receive further fixes — treat this as effectively unpatched. Immediate actions: (1) rotate every OpenAI API credential stored in affected Flowise instances, since any may have been exposed; (2) if running multi-tenant Flowise, isolate workspaces into separate instances/containers rather than relying on the built-in (broken) authorization check; (3) restrict access to the Assistants endpoints to trusted users only and review Flowise access logs for credential-UUID enumeration patterns (sequential or out-of-scope UUID lookups in Assistants API calls); (4) audit vector store and file listings for unexpected cross-workspace content or files uploaded outside a workspace's known change history; (5) given the sunset signal, begin evaluating migration to an actively maintained agent framework for production or customer-facing use.

What does CISA's SSVC say?

Decision Attend
Exploitation poc
Automatable No
Technical Impact total

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

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity
ISO 42001
A.6.2.2 - AI system operation and monitoring
NIST AI RMF
MANAGE 2.3 - AI system risks from third-party resources and components are monitored
OWASP LLM Top 10
LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-67622?

A missing workspace-scoped authorization check in Flowise's OpenAI Assistants integration lets any authenticated user swap in another workspace's credential UUID and retrieve that workspace's OpenAI API credentials, along with cross-workspace assistant metadata and file/vector store listings — and even upload files into a victim's workspace. This is a 9.9 CVSS critical: with low privileges required, no user interaction, and network access, any tenant on a shared Flowise deployment can pivot laterally to every other tenant's OpenAI credentials, opening a direct path to API cost abuse, RAG data exposure, and file/prompt tampering. The EPSS score (0.25%, ~84th percentile) and absence from CISA KEV suggest exploitation isn't yet automated at scale, and CISA's SSVC verdict is only ATTEND — but no public PoC or Nuclei template today doesn't mean one won't appear soon, especially since the vendor reference points to flowiseai.com/sunset, suggesting Flowise itself may be winding down rather than shipping a fix. Any organization running multi-tenant or shared Flowise instances up to 3.1.4 should immediately audit workspace isolation, rotate every OpenAI credential stored in Flowise, and treat this as a forcing function to evaluate migrating off an apparently sunsetting product.

Is CVE-2026-67622 actively exploited?

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

How to fix CVE-2026-67622?

No patched version is listed by the vendor, and the referenced advisory (flowiseai.com/sunset) suggests Flowise may not receive further fixes — treat this as effectively unpatched. Immediate actions: (1) rotate every OpenAI API credential stored in affected Flowise instances, since any may have been exposed; (2) if running multi-tenant Flowise, isolate workspaces into separate instances/containers rather than relying on the built-in (broken) authorization check; (3) restrict access to the Assistants endpoints to trusted users only and review Flowise access logs for credential-UUID enumeration patterns (sequential or out-of-scope UUID lookups in Assistants API calls); (4) audit vector store and file listings for unexpected cross-workspace content or files uploaded outside a workspace's known change history; (5) given the sunset signal, begin evaluating migration to an actively maintained agent framework for production or customer-facing use.

What systems are affected by CVE-2026-67622?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, multi-tenant AI SaaS deployments, LLM API integrations.

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

CVE-2026-67622 has a CVSS v3.1 base score of 9.9 (CRITICAL). The EPSS exploitation probability is 0.32%.

What is the AI security impact?

Affected AI Architectures

agent frameworksRAG pipelinesmulti-tenant AI SaaS deploymentsLLM API integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0055 Unsecured Credentials
AML.T0084 Discover AI Agent Configuration
AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.2
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Flowise through 3.1.4 contains an insecure direct object reference vulnerability in the OpenAI Assistants integration that allows authenticated attackers to access credentials belonging to other workspaces by supplying an arbitrary credential UUID to Assistants endpoints without workspace ownership verification. Attackers can enumerate cross-workspace assistant metadata, retrieve file and vector store listings, and upload files into victim workspaces by exploiting the missing workspace-scoped authorization check in the credential lookup logic.

Exploitation Scenario

An attacker with a low-privilege, authenticated account on a shared Flowise deployment (e.g., a contractor or employee scoped to only their own workspace) calls an Assistants-related endpoint and supplies a credential UUID belonging to a different workspace instead of their own — since the endpoint never verifies the UUID belongs to the caller's workspace, it returns that workspace's OpenAI credential. The attacker then enumerates further UUIDs to map other workspaces' assistant metadata and connected file/vector store listings, identifying which workspaces hold sensitive documents. Using the stolen OpenAI credential and knowledge of the target's assistant/file configuration, the attacker either exfiltrates data via the OpenAI API directly (billed to the victim) or uploads a crafted file into the victim's vector store, poisoning future RAG retrievals for that workspace's AI agents.

Weaknesses (CWE)

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

  • [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
  • [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.

CVSS Vector

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

Timeline

Published
August 6, 2026
Last Modified
August 14, 2026
First Seen
August 7, 2026

Related Vulnerabilities