CVE-2026-91933

Executive Summary

CVE-2026-91933 is an authorization bypass (CWE-639, Insecure Direct Object Reference / horizontal privilege escalation) in Flowise prior to version 3.1.4. The openai-realtime endpoints fail to enforce workspace-level authorization checks, allowing any authenticated user to access and execute tools belonging to ChatFlows in other, tenant-isolated workspaces by supplying an unscoped chatflowid. Because tool execution can trigger external side effects and expose sensitive tool outputs, the impact is a horizontal confidentiality and integrity breach across workspace boundaries. The CVE carries a CVSS base score of 7.1 (High) and no public proof-of-concept, detectable exploit code, or Nuclei template is currently available.

Technical Analysis

Flowise is a low-code / no-code platform for building LLM orchestration flows and agents ("ChatFlows"). ChatFlows can be grouped into workspaces, which act as the tenant boundary. Tools attached to a ChatFlow are callable capabilities — an agent may invoke external APIs, retrieve data, run code, or otherwise perform actions with the privileges and credentials configured on that ChatFlow.

CVE-2026-91933 is a horizontal authorization flaw mapped to CWE-639 (Authorization Bypass Through User-Controlled Key). The core defect: the openai-realtime endpoints accept a client-supplied chatflowid and use it to look up a ChatFlow and its associated tools without verifying that the requesting user belongs to the workspace owning that ChatFlow. Because the workspace scoping check is absent, a valid authenticated session from Workspace A can reference a chatflowid that belongs to Workspace B and retrieve that Flow's tool definitions and/or invoke those tools.

Key technical facts derived directly from the description:

• Vulnerable component: the openai-realtime endpoints.
• Missing control: workspace-level authorization checks (object-level access control).
• User-controlled key: the chatflowid parameter is passed unscoped — i.e., not filtered against the caller's workspace.
• Attack surface: GET requests (retrieve tool definitions) and POST requests (execute tools).
• Access requirements: the attacker must be authenticated (PR:L). A single low-privileged account in any workspace is sufficient. No user interaction is required (UI:N).

The vulnerability class matters more than any individual code path here: the endpoint trusts an object identifier supplied by the client instead of deriving authorization scope from the authenticated session, the canonical IDOR/tenant-bypass pattern. Because tools can "trigger external side effects," successful execution is not merely a read of metadata — it can cause the victim tenant's integrations to take real actions (for example, calling third-party services configured with the victim's credentials). The exact internal function names, route paths beyond openai-realtime, and parameter structures beyond chatflowid are not disclosed in the available intelligence and are therefore not asserted here.

CVSS subscores reinforce the mechanics: AV:N (remotely reachable), AC:H (exploitation requires knowledge of a valid foreign chatflowid and a crafted request against a specific endpoint — conditions beyond the attacker's full control, hence High complexity), PR:L (any authenticated user), C:H (sensitive tool definitions/outputs from other workspaces), I:H (tools can cause external side effects), A:L (limited availability impact, if any).

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available; the chain below is inferred from the vulnerability class (IDOR / workspace-scope authorization bypass) and the NVD description. No specific function names or undocumented endpoints are assumed.

1. Reconnaissance / target identification. The attacker obtains a legitimate low-privileged account on a Flowise instance (self-registration, a compromised user, or a trial/guest account — all plausible in multi-tenant deployments). They identify Flowise instances (see Shodan dorks above) and confirm the platform version is below 3.1.4. They enumerate or guess chatflowid values. If ChatFlow IDs are sequential, short, or otherwise predictable, enumeration is trivial; if they are UUIDs, the attacker needs a valid identifier leak (shared link, logs, screenshots, etc.), which raises the attack complexity — consistent with the AC:H rating.

2. Triggering the flaw. Using their authenticated session, the attacker sends a request to the openai-realtime endpoint and supplies a chatflowid that belongs to a different workspace. The server looks up the object by that key and — because the workspace-scope check is missing — returns data or performs an action for an object the caller should not be able to reference. This is the IDOR step: the object reference (chatflowid) is under attacker control and is not validated against the session's workspace.

3. Payload / execution method (class level). Two request types are abusable:

   • GET: retrieve tool definitions belonging to the victim ChatFlow — leaking the tools, parameters, and possibly configured capability metadata of another tenant.
   • POST: invoke/execute the victim ChatFlow's tools. Because tools can cause external side effects, this POST causes the victim workspace's integrations or actions to run on behalf of the attacker.

4. Post-exploitation impact. The attacker reads sensitive tool outputs (data exfiltration from the victim workspace) and triggers external side effects that the victim tenant legitimately owns (outbound API calls, data writes, notifications, etc.). This yields cross-tenant confidentiality and integrity loss. Depending on what the victim tools are authorized to do, the side effects can range from information disclosure to unauthorized state changes in third-party systems, and could be chained toward further access if a tool holds credentials or privileged integrations.

Impact Assessment

Confidentiality (C:H): Tool definitions and sensitive tool outputs from other workspaces are exposed to any authenticated user. In a multi-tenant Flowise deployment this is a cross-customer data leak.

Integrity (I:H): Tool execution is possible, and tools may trigger external side effects — meaning the attacker can cause the victim workspace's systems to perform unauthorized actions.

Availability (A:L): Limited — primarily indirect (e.g., unintended operations consuming resources or altering state).

Blast radius: Any Flowise deployment below 3.1.4 that (a) is multi-tenant/multi-workspace, and (b) exposes the openai-realtime functionality to authenticated users, including those with only a low-privileged account. Single-workspace deployments have a reduced but non-zero risk (any authenticated user can reach any ChatFlow's tools regardless of intended role boundaries within the workspace).

Exploitability: CVSS 7.1 (High). EPSS 0.00328 (~25.9th percentile), indicating low near-term exploitation likelihood based on current telemetry — but EPSS is a probability, not a guarantee, and the low score likely reflects limited public disclosure/PoC rather than low intrinsic risk. Not in CISA KEV. No known exploitation in the wild as of this report.

Detection Guidance

The following rules are heuristic and must be tuned to the environment. They detect the class of activity (cross-workspace chatflowid access and execution on openai-realtime endpoints), not a single known signature.

Sigma Rule

title: Flowise openai-realtime Cross-Workspace ChatFlow Access (CVE-2026-91933)
id: 2f0b1c9e-7a41-4c8e-9b1d-flowise91933
status: experimental
description: Detects requests to Flowise openai-realtime endpoints carrying a chatflowid, indicative of workspace authorization bypass attempts.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-91933
author: Valters IT Threat Intelligence
date: 2026/01/01
tags:
  - attack.t1190
  - attack.initial_access
  - cve.2026-91933
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-uri-stem|contains:
      - 'openai-realtime'
  selection_param:
    cs-uri-query|contains:
      - 'chatflowid'
  condition: selection_endpoint and selection_param
fields:
  - c-ip
  - cs-uri-stem
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate users accessing their own ChatFlows in the same workspace
level: medium

YARA Rule

rule CVE_2026_91933_Flowise_OpenAI_Realtime_AuthBypass
{
    meta:
        description = "Detects Flowise openai-realtime request patterns referencing chatflowid in logs or captured HTTP artifacts (CVE-2026-91933)"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-91933"
        date = "2026-01-01"
        severity = "high"

    strings:
        $ep1 = "openai-realtime" ascii nocase
        $ep2 = "/openai-realtime/" ascii nocase
        $p1  = "chatflowid" ascii nocase
        $m1  = "GET" ascii
        $m2  = "POST" ascii

    condition:
        ($ep1 or $ep2) and $p1 and ($m1 or $m2)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-91933 Flowise openai-realtime cross-workspace chatflowid access attempt"; flow:established,to_server; http.method; content:"GET"; http.method; content:"POST"; http.uri; content:"openai-realtime"; http.uri; content:"chatflowid"; reference:cve,2026-91933; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-91933; classtype:attempted-user; sid:202691933; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where network.protocol == "http" and
      url.path contains "openai-realtime" and
      url.query contains "chatflowid" ]

Splunk SPL Query

index=web OR index=proxy
(uri_path="*openai-realtime*" OR url="*openai-realtime*")
(uri_query="*chatflowid*" OR url="*chatflowid*")
| stats count min(_time) as first_seen max(_time) as last_seen
        values(http_method) as methods values(status) as status_codes
        by src_ip, uri_path, uri_query
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="flowise,web,attack,">
  <rule id="202691933" level="10">
    <if_sid>31100</if_sid>
    <id>^/api/v1/openai-realtime</id>
    <match>chatflowid</match>
    <description>CVE-2026-91933: Flowise openai-realtime endpoint accessed with chatflowid parameter - possible cross-workspace authorization bypass</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_91933,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — single source (OSV) claims a fix; not independently confirmed). Treat the 3.1.4 fix as unverified and validate behavior after updating. No CVE-specific workaround is published by the vendor.

1. Immediate mitigations

   • Restrict network access to the openai-realtime endpoints to trusted networks/users where possible; do not expose them unnecessarily to all authenticated users.
   • Reduce the attack surface: audit which ChatFlows expose tools that cause external side effects and disable or scope those tools until patched.
   • Tighten account provisioning: limit who can self-register or obtain low-privileged accounts, since exploitation only requires authentication.
   • If a WAF/proxy is available, alert (and optionally block) requests to openai-realtime endpoints carrying chatflowid values not associated with the caller's known workspace (server-side enforcement is preferred over WAF, see hardening).
   • Monitor tool-execution side effects in victim tenants (outbound API calls) for anomalies.

2. Patch / upgrade steps

   • Upgrade Flowise to 3.1.4 or later, per the claimed single-source fix (OSV). Because patch confidence is low, verify with the vendor's official release notes/advisory before relying on it.
   • After upgrading, verify the fix behaviorally: from Workspace A, attempt to GET/POST against a chatflowid owned by Workspace B and confirm a 401/403 or equivalent denial. Do not consider the issue resolved on version string alone.
   • Inventory all instances (including dev/test/staging clones) and apply the upgrade consistently.

3. Long-term hardening

   • Implement object-level authorization centrally: derive workspace scope from the authenticated session and reject any request where the referenced chatflowid is not owned by the caller's workspace. Apply this to every endpoint that accepts a client-supplied resource identifier — not just openai-realtime.
   • Adopt an authorization testing gate: add regression tests, SAST/DAST checks for IDOR/tenant isolation (CWE-639), and pre-release cross-tenant access tests.
   • Use unpredictable, non-enumerable identifiers for ChatFlows to reduce the ease of enumeration (defense in depth; not a substitute for proper authorization).
   • Monitor vendor advisories and the OSV/NVD entries until patch status is confirmed and upgraded to verified.

References

• NVD — CVE-2026-91933: https://nvd.nist.gov/vuln/detail/CVE-2026-91933
• OSV — package/version entry claiming fix in Flowise 3.1.4 (single source; unconfirmed)
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• Flowise project repository & release notes (verify 3.1.4 changelog): https://github.com/FlowiseAI/Flowise
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-91933 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploitation evidence: No exploit-in-the-wild evidence, no public PoC, no Nuclei template, and no CISA KEV listing at time of writing. EPSS 0.00328 (~25.9th percentile). All exploitation detail above is inferred from the vulnerability class and must be re-validated as independent intelligence emerges.