CVE-2026-90533

Executive Summary

CVE-2026-90533 is a broken access control (CWE-862) vulnerability in Flowise, an open-source low-code LLM application builder, affecting all versions before 3.1.4. The endpoint GET /api/v1/organizationuser fails to enforce authorization scoping, allowing any authenticated organization member to retrieve the full user record of the organization owner — including the owner's bcrypt password hash and temporary tokens. Successful exploitation exposes the highest-privileged account's credential material, enabling offline password cracking and full account takeover of the organization owner.

Technical Analysis

The vulnerability class here is missing authorization (CWE-862) — the application performs authentication but does not verify that the requesting principal is permitted to access the specific object being requested. This is a horizontal-to-vertical privilege escalation pattern: a low-privilege authenticated user (any organization member) can reach an object owned by a high-privilege principal (the organization owner).

The attack surface is the REST API endpoint GET /api/v1/organizationuser, which according to the NVD description returns a user record. The endpoint accepts a user ID parameter (the description states an attacker "can query the endpoint with any user ID"), meaning the server trusts a client-supplied identifier without binding it to the authenticated session's own organization membership or role. Because no server-side check confirms that the caller is the owner or an administrator, the response object is returned to any authenticated organization member.

The sensitivity arises from the contents of the returned record rather than from code execution. Per the description, the response includes:

• the owner's bcrypt password hash, and
• temporary tokens.

Exposing a bcrypt hash does not yield immediate plaintext credentials, but bcrypt is a password-based key derivation function and is therefore vulnerable to offline dictionary and brute-force cracking proportional to password entropy and cost factor. Weak or reused owner passwords are recoverable in practical timeframes with commodity GPU hardware. Temporary tokens, by contrast, may be usable directly if they remain valid at the time of retrieval, collapsing the attack from "crack-then-login" into "replay-now."

No function names, internal class names, middleware identifiers, or database schema details are available in the supplied data; the analysis above is limited to the endpoint, the object returned, the role relationship described, and the CWE classification. Nothing further should be inferred about the implementation.

Exploitation Scenarios

No public proof-of-concept, Nuclei template, or exploit code was identified for this CVE. The attack chain below is inferred from the vulnerability class (CWE-862, broken access control) and the explicit details in the NVD description. No public PoC available; attack chain is inferred from vulnerability class.

1) Reconnaissance / target identification. An attacker identifies an internet-exposed or internally reachable Flowise instance running a version below 3.1.4. Shodan enumeration using the HTTP title/body markers Flowise and the application favicon hash identifies candidate hosts. The attacker must obtain at least one valid low-privilege account within the target organization — this can come from a legitimate but limited account, a compromised member credential, or self-registration where the deployment permits it. Authentication is a hard prerequisite: the CWE-862 flaw is an authorization failure, not an authentication bypass.

2) Triggering the flaw class. With a valid member session, the attacker issues a request to GET /api/v1/organizationuser, supplying a user ID. Because the endpoint does not verify that the requested ID belongs to the caller or that the caller holds owner/admin privileges, the authorization control is absent or ineffective. The attacker enumerates or guesses the owner's user ID — sequential, low-entropy, or otherwise predictable identifiers make this trivial; the description's phrasing ("query the endpoint with any user ID") indicates no ownership validation is enforced on the identifier.

3) Payload / execution method. At the vulnerability-class level, exploitation is a single authenticated HTTP GET with a manipulated identifier — no injection payload, no code execution, and no special tooling. Data exfiltration is achieved simply by reading the JSON response body, which contains the owner's full user record: bcrypt password hash and temporary tokens.

4) Post-exploitation impact. The attacker removes the hash from the environment and cracks it offline with tools such as hashcat (mode 3200 for bcrypt), avoiding any further network contact and therefore any lockout or rate-limit countermeasures. Alternatively, if the temporary tokens are still within their validity window, the attacker uses them directly to assume the owner session. Either path yields account takeover of the organization's highest-privileged account, from which the attacker inherits the owner's access to flows, credentials, connected model providers, API keys, and any downstream systems those integrations reach.

Detection opportunity. Because the exploit is a well-formed, authenticated GET, it will not trigger injection-oriented signatures. Detection must rely on behavioral signals: a single member account requesting organizationuser with an ID that does not match its own, repeated requests with varying IDs (enumeration), or a rapid sequence of GETs to that path in a short window.

Impact Assessment

The confidentiality impact is high: the vulnerability discloses credential material (bcrypt hash) and temporary tokens belonging to the most privileged account in the organization. Integrity and availability impacts on the vulnerable component are indirect but severe — once the owner account is taken over, the attacker can modify or delete flows, exfiltrate connected secrets, and pivot through any integration the owner administers.

Under the modeled CVSS v3.1 vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, the base characteristics are: Network attack vector (the API is typically reachable over HTTP/HTTPS), Low attack complexity (a single crafted request), Low privileges required (any authenticated organization member), No user interaction, Unchanged scope, High confidentiality impact, and No direct integrity or availability impact at the moment of exploitation. EPSS has not yet scored this CVE; no exploit-in-the-wild evidence and no CISA KEV listing were identified.

Blast radius. Every Flowise deployment below 3.1.4 that (a) exposes the API to untrusted networks and (b) has more than one user in an organization is potentially affected. Multi-tenant or multi-member workspaces carry the widest exposure because the precondition — an authenticated member account — is easiest to satisfy. Single-user, non-exposed deployments carry minimal practical risk. The upstream consequence of a successful exploit is disproportionate to the entry cost: a low-privilege member escalates straight to the owner, the account most likely to hold API keys for OpenAI, Anthropic, or other model providers, database credentials, and webhook secrets.

Detection Guidance

Sigma Rule

title: Flowise Broken Access Control - Organization User Enumeration (CVE-2026-90533)
id: 8f2c1a44-9053-4d7b-b6e1-0a7c5e21d9aa
status: experimental
description: Detects authenticated requests to the Flowise organizationuser API endpoint that may indicate unauthorized retrieval of the organization owner's user record, including password hash and temporary tokens.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-90533
author: Valters IT Threat Intelligence
date: 2026-01-01
tags:
  - attack.t1190
  - attack.initial_access
  - cve.2026-90533
logsource:
  category: webserver
detection:
  selection_endpoint:
    cs-uri-stem|contains: '/api/v1/organizationuser'
    cs-method: 'GET'
  selection_suspicious:
    cs-uri-query|contains:
      - 'userId='
      - 'id='
  condition: selection_endpoint
fields:
  - c-ip
  - cs-username
  - cs-uri-query
  - sc-status
falsepositives:
  - Legitimate administrative consoles retrieving their own user record
  - Organization management UI performing routine profile lookups
level: medium

YARA Rule

rule CVE_2026_90533_Flowise_OrganizationUser_BAC
{
    meta:
        description = "Detects Flowise source or build artifacts referencing the vulnerable organizationuser endpoint (CVE-2026-90533, pre-3.1.4)"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-90533"
        date = "2026-01-01"
        severity = "high"

    strings:
        $ep = "/api/v1/organizationuser" ascii wide nocase
        $ep2 = "organizationuser" ascii wide nocase
        $ver = "flowise" ascii wide nocase

    condition:
        $ver and any of ($ep*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-90533 Flowise Organization User Access Control Bypass Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/v1/organizationuser"; http.uri; content:"userId="; fast_pattern; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-user; reference:cve,2026-90533; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-90533; sid:9005331; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [http where http.request.method == "GET" and
    http.request.path == "/api/v1/organizationuser"]
  [http where http.request.method == "GET" and
    http.request.path == "/api/v1/organizationuser"]

Splunk SPL Query

index=web sourcetype=access_common
| search method=GET uri_path="/api/v1/organizationuser*"
| rex field=uri_query "userId=(?<requested_user_id>[^&]+)"
| stats count min(_time) as first_seen max(_time) as last_seen
        values(requested_user_id) as requested_ids
        dc(requested_user_id) as distinct_ids
        by src_ip user
| where count > 3 OR distinct_ids > 1
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"),
       last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="flowise,web,access_control,">
  <rule id="100533" level="10">
    <decoded_as>json</decoded_as>
    <field name="url">/api/v1/organizationuser</field>
    <field name="method">GET</field>
    <description>CVE-2026-90533 - Flowise organizationuser endpoint accessed; possible broken access control / owner record disclosure attempt.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>

  <rule id="100534" level="12" frequency="5" timeframe="120">
    <if_matched_sid>100533</if_matched_sid>
    <same_source_ip />
    <description>CVE-2026-90533 - Repeated Flowise organizationuser requests from same source; suspected user ID enumeration.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence from any tracked source. No vendor advisory, commit reference, or hotfix was supplied in the source data. The version boundary below (< 3.1.4) is derived solely from the NVD description. Treat patch availability as unverified and confirm with the vendor before relying on an upgrade as the sole control.

1) Immediate mitigations (assume no patch is available).

• Restrict network access to the Flowise management API. Place /api/v1/organizationuser and the rest of the API behind a VPN, mTLS gateway, or IP allowlist so that only trusted administrative networks can reach it. This removes the exposed attack surface that makes the precondition (any authenticated member) reachable.
• Enforce strict, non-predictable user identifiers if the deployment's user IDs are sequential or low-entropy. Note that this is defense-in-depth only — the underlying flaw is missing authorization, not identifier guessability.
• Apply a reverse-proxy or API-gateway authorization rule that rejects GET /api/v1/organizationuser requests where the requested user ID does not match the authenticated session's own ID, or where the caller lacks an owner/admin role. This compensates for the missing application-layer check.
• Reduce the member population: audit organizations for stale or unnecessary member accounts and remove them, since the vulnerability requires only one valid member session.
• Rotate credentials and invalidate sessions/tokens for organization owner accounts in any deployment where source-IP logs show the endpoint was accessed by a non-owner. Treat owner bcrypt hashes and temporary tokens as potentially compromised; rotate all API keys and downstream secrets the owner account can reach.

2) Patch / upgrade steps.

• Upgrade Flowise to 3.1.4 or later, which is the version boundary given in the NVD description. Because no patch reference is available, verify the fix by (a) confirming the deployed version after upgrade and (b) re-testing the endpoint with a low-privilege member account to confirm it can no longer retrieve another user's record. Do not assume the upgrade resolves the issue without verification.
• Re-run the credential rotation step above for any deployment that was exposed while running a vulnerable version.

3) Long-term hardening.

• Adopt object-level authorization as a first-class control: every API handler that accepts an object identifier must bind that identifier to the authenticated principal's own scope or verified role. Broken access control at the endpoint level (CWE-862) is a recurring class and is not eliminated by input validation or WAF rules alone.
• Implement centralized authorization middleware and enforce it by default so new endpoints inherit a deny-by-default posture rather than requiring per-handler opt-in.
• Add continuous authorization testing (automated regression suites and periodic manual review) to CI/CD so that object-level access failures are caught before release.
• Instrument and alert on sensitive-endpoint access patterns — particularly single-object retrieval endpoints that return credential material — and avoid returning credential hashes or temporary tokens in any API response at all.
• Maintain an asset inventory with version tracking so affected Flowise instances can be located and remediated quickly when a patch lands.

References

• NVD — CVE-2026-90533: https://nvd.nist.gov/vuln/detail/CVE-2026-90533
• MITRE CWE-862, Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
• Flowise project repository and release notes (verify the 3.1.4 release directly with the vendor): https://github.com/FlowiseAI/Flowise
• FIRST EPSS (no score currently published for this CVE): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-90533 not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Exploit-in-the-wild and threat actor note: No public proof-of-concept, Nuclei template, or exploit code was identified for CVE-2026-90533 at the time of writing, and the CVE is not listed in CISA KEV. No threat actor campaign has been attributed. Exploitation requires a valid low-privilege authenticated account and is a single, non-noisy authenticated request, making real-world abuse plausible but difficult to detect without the behavioral monitoring described above. Treat "no PoC" as a current-state observation, not a durable one — broken access control vulnerabilities are frequently weaponized quickly once disclosed.