CVE-2026-90533: Flowise IDOR exposes org owner's

CISO Take

Flowise before 3.1.4 has a broken access control flaw in GET /api/v1/organizationuser that lets any authenticated organization member query another user's record by ID and receive the target's full profile — including their bcrypt password hash and temporary tokens. Because any low-privileged member can target the organization owner's user ID, this is a direct path to compromising the highest-privileged account in a Flowise deployment, which typically holds access to every connected LLM API key, credential, and agent workflow in the tenant. There is no CVSS score, EPSS data, KEV listing, or public exploit/scanner coverage yet, so exploitation likelihood signals are absent — but the attack requires no special tooling, just a valid low-privileged account and a hash cracker, making it trivial once discovered. Any organization running self-hosted or multi-tenant Flowise below 3.1.4 should patch immediately, rotate the organization owner's password and any temporary tokens, and audit access logs on /api/v1/organizationuser for cross-user ID queries as a compromise indicator.

Sources: NVD GitHub Advisory vulncheck.com ATLAS

What is the risk?

No formal CVSS/EPSS scoring is available and the flaw is not in CISA KEV or paired with a public exploit or Nuclei template, so opportunistic mass exploitation risk currently looks low. However, the practical severity is high: this is a broken object-level authorization (IDOR/BOLA) issue where the trust boundary is the authenticated-session check rather than per-object ownership validation, so exploitation requires only an existing low-privileged organization account — a bar many multi-tenant or team-managed Flowise deployments will meet. The blast radius is the entire tenant, since the exposed record belongs to the organization owner, the account most likely to hold elevated permissions, connected credentials, and billing/admin control.

How does the attack unfold?

Initial Access

An attacker with any authenticated, low-privileged organization member account queries GET /api/v1/organizationuser using the organization owner's user ID.

AML.T0049

Exploitation

The endpoint fails to verify object-level authorization and returns the owner's full user record, including bcrypt password hash and temporary tokens.

AML.T0106

Credential Cracking

The attacker cracks the exfiltrated bcrypt hash offline to recover the owner's plaintext password.

AML.T0012

Impact

The attacker logs in as the organization owner, gaining full administrative control over the Flowise instance, its stored credentials, and all agent workflows.

AML.T0012

Initial Access

An attacker with any authenticated, low-privileged organization member account queries GET /api/v1/organizationuser using the organization owner's user ID.

AML.T0049

Exploitation

The endpoint fails to verify object-level authorization and returns the owner's full user record, including bcrypt password hash and temporary tokens.

AML.T0106

Credential Cracking

The attacker cracks the exfiltrated bcrypt hash offline to recover the owner's plaintext password.

AML.T0012

Impact

The attacker logs in as the organization owner, gaining full administrative control over the Flowise instance, its stored credentials, and all agent workflows.

AML.T0012

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

6.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 10% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I None

A None

What should I do?

1 step

Upgrade to Flowise 3.1.4 or later immediately. Until patched, restrict organization membership to trusted users only and avoid onboarding untrusted members to multi-user Flowise instances. After patching, rotate the organization owner's password and invalidate/reissue any temporary tokens, since the hash and tokens may already have been exposed. Review access logs for GET /api/v1/organizationuser requests referencing user IDs other than the requester's own ID as an indicator of exploitation attempts. Longer term, ensure the endpoint enforces per-object authorization checks (verify the requester is either the target user or has an explicit admin role) rather than only checking authentication.

How is it classified?

Auth Bypass Data Leakage Agent Framework AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-90533?

Flowise before 3.1.4 has a broken access control flaw in GET /api/v1/organizationuser that lets any authenticated organization member query another user's record by ID and receive the target's full profile — including their bcrypt password hash and temporary tokens. Because any low-privileged member can target the organization owner's user ID, this is a direct path to compromising the highest-privileged account in a Flowise deployment, which typically holds access to every connected LLM API key, credential, and agent workflow in the tenant. There is no CVSS score, EPSS data, KEV listing, or public exploit/scanner coverage yet, so exploitation likelihood signals are absent — but the attack requires no special tooling, just a valid low-privileged account and a hash cracker, making it trivial once discovered. Any organization running self-hosted or multi-tenant Flowise below 3.1.4 should patch immediately, rotate the organization owner's password and any temporary tokens, and audit access logs on /api/v1/organizationuser for cross-user ID queries as a compromise indicator.

Is CVE-2026-90533 actively exploited?

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

How to fix CVE-2026-90533?

Upgrade to Flowise 3.1.4 or later immediately. Until patched, restrict organization membership to trusted users only and avoid onboarding untrusted members to multi-user Flowise instances. After patching, rotate the organization owner's password and invalidate/reissue any temporary tokens, since the hash and tokens may already have been exposed. Review access logs for GET /api/v1/organizationuser requests referencing user IDs other than the requester's own ID as an indicator of exploitation attempts. Longer term, ensure the endpoint enforces per-object authorization checks (verify the requester is either the target user or has an explicit admin role) rather than only checking authentication.

What systems are affected by CVE-2026-90533?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code AI orchestration platforms, multi-tenant SaaS deployments.

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

CVE-2026-90533 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.19%.

What is the AI security impact?

Affected AI Architectures

agent frameworkslow-code AI orchestration platformsmulti-tenant SaaS deployments

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Flowise before 3.1.4 contains a broken access control vulnerability in GET /api/v1/organizationuser that allows any authenticated organization member to retrieve the organization owner's full user record including bcrypt password hash and temporary tokens. Attackers can query the endpoint with any user ID to obtain the owner's credential hash for offline cracking, enabling account takeover of the highest-privileged account.

Exploitation Scenario

An attacker who has legitimate but low-privileged access to a Flowise organization (e.g., a contractor, disgruntled employee, or someone who signed up to a shared multi-tenant instance) enumerates or guesses the organization owner's user ID and calls GET /api/v1/organizationuser with that ID. The endpoint returns the owner's full user record, including the bcrypt password hash and any temporary tokens, without verifying the requester has rights to view it. The attacker takes the hash offline and cracks it (feasible if the owner's password is weak or reused), then logs in as the owner. With owner-level access, the attacker can view and exfiltrate every stored LLM API key and credential, modify or hijack production agent flows, and pivot into any downstream system those agents are connected to.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.