CVE-2026-67622: Flowise: IDOR in Assistants API leaks OpenAI credentials
CRITICAL CISA: ATTENDA 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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | — | No patch |
Do you use Flowise? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
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?
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:
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
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
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
Primary
CWE-639 Authorization Bypass Through User-Controlled Key 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 References
- flowiseai.com/sunset vendor-advisory
- github.com/Caycon/cve-advisories/blob/main/2026/Flowise/CVE-2026-67622.md technical-description exploit
- vulncheck.com/advisories/flowise-idor-in-openai-assistants-integration third-party-advisory
Timeline
Related Vulnerabilities
CVE-2025-71338 10.0 Flowise: unauthenticated file write enables RCE
Same package: flowise CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same package: flowise CVE-2025-61913 9.9 Flowise: path traversal in file tools leads to RCE
Same package: flowise CVE-2026-40933 9.9 Flowise: RCE via MCP stdio command injection
Same package: flowise CVE-2026-46442 9.9 Flowise: sandbox escape enables authenticated RCE
Same package: flowise