CVE-2026-91930

Executive Summary

CVE-2026-91930 is a broken access control / improper privilege management flaw (CWE-266 — Incorrect Privilege Assignment) in Flowise, an open-source low-code platform for building LLM applications and AI agents. Flowise versions before 3.1.4 fail to scope enterprise organization and workspace membership API endpoints to the caller's tenant, allowing any authenticated user to supply arbitrary organization identifiers. Successful exploitation enables an attacker to add themselves as an organization owner and create workspaces, escalating to administrative access within victim organizations — a full confidentiality, integrity, and availability impact (CVSS 7.5). No public proof-of-concept, exploit code, or Nuclei template is currently available, and the vulnerability is not listed in CISA KEV.

Technical Analysis

Flowise is a widely deployed low-code platform for orchestrating LLM chains, agents, and tool integrations. In enterprise deployments, Flowise exposes multi-tenant primitives: organizations, workspaces, and organization-user memberships. These constructs allow a single Flowise deployment to serve multiple business units, customers, or teams with logical separation between their respective assets.

The vulnerability described by NVD is a tenant isolation failure. The enterprise organization and workspace membership APIs — specifically the organization-user and workspace endpoint families — accept tenant-scoping identifiers (organization IDs) from the requesting client but fail to validate that the caller actually belongs to the referenced organization. In other words, the authorization decision relies upon a client-supplied identifier rather than being derived from the authenticated session and enforced server-side against the caller's own tenant context.

This maps directly to CWE-266 (Incorrect Privilege Assignment) and, more broadly, to CWE-639 (Authorization Bypass Through User-Controlled Key) as the underlying mechanism. The missing control is a server-side authorization check that binds the submitted organization ID to the authenticated principal's membership set. Because that check is absent, any authenticated user can reference an organization ID they do not belong to and have membership-mutating operations applied against that foreign tenant.

Two distinct but related exploit paths are implied by the NVD description:

1. Membership self-assignment (organization-user endpoint): An authenticated user submits a request that creates or modifies an organization-user membership record, specifying a victim organization ID and assigning themselves an owner role. Because the endpoint does not verify the caller's relationship to the target organization, the membership is created.
2. Workspace creation against a foreign tenant (workspace endpoint): With an owner membership in place (or via the same missing scoping check on the workspace endpoint), the attacker creates workspaces within the victim organization, gaining a foothold into the tenant's resource namespace.

The attack surface is the Flowise REST API (network-exposed, AV:N) and requires only a valid low-privilege authenticated session (PR:L). The AC:H (High) subscore in the CVSS vector reflects that exploitation requires some knowledge of the target environment — specifically, obtaining a valid victim organization ID — which is not trivially brute-forceable and often requires an additional reconnaissance or information-disclosure step. No user interaction is required (UI:N), and the impact across all three CIA pillars is High.

Notably, CWE-266 is classified under CWE-269 (Improper Privilege Management), which CISA lists in its Top 25 Most Dangerous Software Weaknesses. Improper privilege assignment in multi-tenant SaaS platforms is particularly dangerous because a single authentication foothold can cross the tenant boundary and compromise unrelated customers.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (tenant isolation failure in membership APIs) and the NVD description. No specific function names, code paths, or payload strings are fabricated.

1. Reconnaissance and target identification. The attacker identifies a reachable Flowise instance — typically via internet-wide scanning (Shodan: http.title:"Flowise", product:"Flowise") or because the deployment is a shared/enterprise instance they already have access to as a low-privilege user. The attacker's goal during reconnaissance is to obtain (a) a valid authenticated session/API key and (b) the organization ID of a target tenant. Organization IDs may be discoverable through response bodies of their own tenant, sequential/predictable identifiers, leaked references in shared resources, or other information disclosure — this reconnaissance step accounts for the High attack-complexity subscore.

2. Triggering the flaw class. With a low-privilege authenticated session, the attacker issues requests against the Flowise enterprise organization-user and workspace API endpoints. The attacker supplies an organization ID in the request that corresponds to a victim tenant rather than their own. The server fails to verify that the authenticated principal is a member of — or authorized to mutate — the referenced organization. This is the core missing-authorization-check condition.

3. Payload/execution at the vulnerability-class level. The attacker crafts membership-mutating requests that (i) add themselves as an owner of the victim organization via the organization-user endpoint, and/or (ii) create workspaces within the victim organization via the workspace endpoint. No payload injection or memory corruption is involved — the "exploit" is a legitimate API request with an attacker-controlled tenant identifier. Because the operation is a normal, well-formed API call, it blends with benign administrative traffic.

4. Post-exploitation impact. Once the attacker holds an owner membership, they have administrative control over the victim organization and its workspaces. From this position an attacker can read, modify, or delete victim tenant assets (LLM flows, credentials, tool configurations, knowledge bases), pivot to further resources, persist by creating additional memberships or workspaces, and disrupt operations (A:H). Because Flowise often stores integration secrets (API keys to third-party LLM and tooling providers), compromise of a tenant can cascade into downstream service compromise. Full C/I/A impact is consistent with the CVSS subscore set.

Impact Assessment

• Confidentiality (C:H): An attacker with owner-level access to a victim organization can read that tenant's flows, configurations, and stored integration secrets.
• Integrity (I:H): The attacker can create, modify, or delete workspaces, memberships, and tenant resources — a full tenant-integrity compromise.
• Availability (A:H): Owner-level access permits destructive actions against victim tenant resources.
• Scope (S:U): The CVSS vector treats the impact as confined to the vulnerable component's security scope, though in practice cross-tenant compromise affects multiple business entities served by the same deployment.
• Blast radius: Any organization sharing the same Flowise enterprise deployment as the attacker's authenticated account is at risk. Multi-tenant SaaS, MSP, and shared-enterprise deployments have the highest exposure; single-tenant deployments are lower risk but not immune if multiple internal teams share the instance.
• Privileges required (PR:L): Only a basic authenticated account is needed, so the vulnerability is attractive to malicious insiders, compromised user accounts, and any external attacker who can register or obtain a low-privilege account.

Because exploitation is an authenticated API misuse rather than an obviously malicious payload, detection relies on authorization-logic auditing rather than signature matching.

Detection Guidance

Sigma Rule

title: Flowise Tenant Isolation Bypass - Cross-Organization Membership or Workspace Mutation
id: 6f2b1c9a-3d47-4e21-9b0a-7c5e1f8a2d34
status: experimental
description: Detects Flowise API requests that mutate organization-user membership or create workspaces referencing an organization identifier, indicative of CVE-2026-91930 tenant isolation bypass.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91930
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1078.004
  - attack.privilege_escalation
  - cve.2026-91930
logsource:
  category: web
  product: flowise
detection:
  selection_endpoint:
    cs-uri-path|contains:
      - '/organizationuser'
      - '/organization-user'
      - '/workspace'
  selection_method:
    cs-method:
      - 'POST'
      - 'PUT'
      - 'PATCH'
  selection_org_id:
    cs-uri-query|contains: 'organizationId'
    # or body field organizationId depending on log enrichment
  condition: selection_endpoint and selection_method
falsepositives:
  - Legitimate administrators provisioning membership within their own organization
level: medium

YARA Rule

rule CVE_2026_91930_Flowise_Tenant_Isolation_Bypass
{
    meta:
        description = "Detects HTTP request artifacts referencing Flowise enterprise organization-user and workspace API endpoints with client-supplied organization identifiers"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91930"
        cve = "CVE-2026-91930"
        date = "2026-01-01"

    strings:
        $api_orguser = "/api/v1/organizationuser" ascii nocase
        $api_orguser2 = "/organizationuser" ascii nocase
        $api_workspace = "/api/v1/workspace" ascii nocase
        $orgid_param = "organizationId" ascii nocase
        $flowise_ua = "flowise" ascii nocase

    condition:
        (
            $api_orguser or $api_orguser2 or $api_workspace
        )
        and $orgid_param
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91930 Flowise Cross-Tenant Organization/Workspace Mutation Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"organizationuser"; nocase; http.request_body; content:"organizationId"; nocase; reference:cve,2026-91930; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91930; classtype:attempted-admin; sid:2026919301; rev:1;)

alert http any any -> any any (msg:"CVE-2026-91930 Flowise Cross-Tenant Workspace Creation Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"workspace"; nocase; http.request_body; content:"organizationId"; nocase; reference:cve,2026-91930; classtype:attempted-admin; sid:2026919302; rev:1;)

Elastic Detection

sequence by user.id with maxspan=5m
  [ network where
      http.request.method in ("POST", "PUT", "PATCH") and
      http.request.uri : ("*organizationuser*", "*organization-user*", "*workspace*") ]
  [ network where
      http.request.method in ("POST", "PUT", "PATCH") and
      http.request.body : "*organizationId*" ]

Splunk SPL Query

index=web sourcetype=flowise OR sourcetype=access_combined
| where match(lower(uri_path), "(organizationuser|organization-user|workspace)")
| where method IN ("POST", "PUT", "PATCH")
| where match(lower(request_body), "organizationid") OR match(lower(uri_query), "organizationid")
| stats count, values(uri_path) as endpoints, values(request_body) as bodies by src_ip, user, org_id
| where count > 0
| table src_ip user endpoints count bodies

Deployment note: the above query assumes request bodies are logged. In many deployments only URI and status codes are captured; in that case, pivot to high-rate 200/201 responses on the organization-user and workspace endpoints from a single authenticated principal, especially where the target organization differs from the principal's own.

Wazuh OSSEC Rule

<group name="flowise,cve-2026-91930,web,">
  <rule id="100930" level="8">
    <decoded_as>json</decoded_as>
    <field name="url">organizationuser|organization-user</field>
    <field name="method">POST|PUT|PATCH</field>
    <description>CVE-2026-91930: Flowise organization-user membership mutation attempt (possible cross-tenant escalation)</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>

  <rule id="100931" level="8">
    <decoded_as>json</decoded_as>
    <field name="url">workspace</field>
    <field name="method">POST</field>
    <description>CVE-2026-91930: Flowise workspace creation referencing organization identifier (possible tenant isolation bypass)</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source claims patch; not independently confirmed).

1. Immediate mitigations (if upgrade is not yet possible):

• Restrict network reachability of the Flowise instance. If it is enterprise/multi-tenant, place it behind authenticated access control and do not expose the API to untrusted networks or the public internet.
• Require every enterprise user to authenticate with unique, individually controlled credentials; disable any self-registration or shared-account patterns that let an outsider obtain a low-privilege account.
• Enforce the principle of least privilege on all Flowise service accounts; do not use a single superuser API key for routine operations.
• Monitor and alert on membership or workspace mutations (see detection guidance) and immediately investigate any organization-user or workspace changes that were not explicitly provisioned.
• Where feasible, temporarily disable or lock down the enterprise organization/workspace provisioning endpoints to platform administrators only.

2. Patch / upgrade steps:

• Upgrade Flowise to 3.1.4 or later, which the OSV source claims resolves the tenant scoping issue. Treat this as a single-source claim and verify the release notes and changelog directly against the vendor repository before relying on it.
• Because the patch is only CLAIMED, test in a non-production environment first. After upgrade, re-test the organization-user and workspace endpoints with a low-privilege account referencing a foreign organization ID to confirm the server now rejects the cross-tenant request (expected: HTTP 403/404).
• Rotate any integration secrets, API keys, or credentials stored in Flowise tenants that may have been exposed before remediation.

3. Long-term hardening:

• Adopt a server-side authorization model in which tenant context is derived only from the authenticated session, never from client-supplied parameters. Treat any request-supplied organization/workspace ID as untrusted input and validate membership against the principal before mutation.
• Implement centralized authorization checks (policy engine / middleware) for all enterprise endpoints rather than per-handler ad hoc validation, to prevent similar tenant-scoping gaps.
• Add automated regression tests that assert cross-tenant access returns 403/404 for every membership and workspace endpoint.
• Enforce tenant isolation testing in CI/CD and include broken-access-control (CWE-639, CWE-266) checks in security review gates.
• Log and continuously monitor all authorization decisions, with alerting on cross-tenant access attempts and privilege-assignment changes.

References

1. National Vulnerability Database — CVE-2026-91930: https://nvd.nist.gov/vuln/detail/CVE-2026-91930
2. OSV — Flowise vulnerability record (single-source patch claim for 3.1.4): https://osv.dev/
3. MITRE CWE-266 — Incorrect Privilege Assignment: https://cwe.mitre.org/data/definitions/266.html
4. MITRE ATT&CK — T1078.004 Valid Accounts: Cloud Accounts: https://attack.mitre.org/techniques/T1078/004/
5. Flowise project repository and release notes (verify 3.1.4 patch contents): https://github.com/FlowiseAI/Flowise

Threat actor / exploit-in-the-wild status: No public proof-of-concept, exploit code, or Nuclei template is known as of this report. CVE-2026-91930 is not listed in CISA KEV, and no named threat actor campaigns have been attributed. EPSS has not yet been scored by FIRST.org. Detection should focus on authenticated cross-tenant API abuse rather than known attack signatures.