GHSA-48m6-ch88-55mj: Flowise: Mass Assignment allows cross-tenant org takeover

GHSA-48m6-ch88-55mj HIGH
Published April 16, 2026
CISO Take

Flowise's registration endpoint fails to enforce an input allowlist, letting unauthenticated attackers inject server-managed fields — including organizationId and owner roleId — at account creation time, granting instant owner-level access to any existing tenant with a single crafted HTTP request. This is a severe trust boundary violation: Flowise deployments store embedded LLM API keys, workflow logic, and agent tool credentials scoped per organization, all of which are exposed once an attacker joins as owner. No public exploit code exists and active exploitation has not been confirmed, but the attack requires only knowledge of a target organization UUID — discoverable through prior API interaction, error messages, or enumeration — making this trivially weaponizable post-disclosure. Upgrade to Flowise 3.1.0 immediately; if patching is delayed, block the /api/v1/account/register endpoint at the WAF or network layer and audit existing accounts for unexpected organization associations or anomalous createdBy timestamps.

Sources: GitHub Advisory ATLAS

What is the risk?

High risk. Network-exploitable with no authentication or user interaction required. The CVSS AC:H rating reflects that an attacker must know or guess a target organization UUID, which moderates the base score to 8.1 but does not meaningfully reduce real-world risk given UUID discoverability. In AI agent deployments, cross-tenant access translates directly to exposure of LLM provider API keys, proprietary workflow automation, and any data processed through agents. The package has 37 prior CVEs, indicating a historically weak security posture. No active exploitation or public PoC currently confirmed, but the vulnerability class is well-understood and the PoC in the advisory is complete.

How does the attack unfold?

Reconnaissance
Attacker registers a legitimate account on the Flowise instance to observe API response structure and extract their own organization UUID as a reference for targeting other tenants.
AML.T0006
Mass Assignment Injection
Attacker sends a crafted POST to /api/v1/account/register injecting a target organization's UUID and owner roleId alongside standard registration fields, exploiting the absent server-side allowlist.
AML.T0049
Privileged Account Establishment
Server persists the injected organization association and role mappings, creating the attacker's account with owner-level membership in the victim tenant without any authorization check.
AML.T0021
Cross-Tenant Data Access
Attacker authenticates with the new account and accesses the victim organization's AI agents, embedded LLM provider API keys, workflow configurations, and processed data with full owner privileges.
AML.T0085

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Flowise npm <= 3.0.13 3.1.0

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1
8.1 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR None
UI None
S Unchanged
C High
I High
A High

What should I do?

5 steps
  1. Patch: Upgrade to Flowise 3.1.0 which enforces DTO-based validation on the registration endpoint.

  2. Immediate workaround: Disable public registration or restrict /api/v1/account/register to trusted IP ranges via WAF or reverse proxy rules.

  3. Detection: Audit the accounts table for entries where createdBy/updatedBy fields contain UUIDs not matching the created user, or where organizationUser records were created at the same timestamp as account registration.

  4. Incident response: Review registration logs for payloads containing 'organization', 'organizationUser', or 'workspaceUser' keys outside the standard schema.

  5. Rotate any LLM provider API keys stored in affected Flowise organizations as a precaution.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, robustness and cybersecurity Article 9 - Risk management system
ISO 42001
A.6.1.2 - Information access restriction A.8.4 - Access to source code
NIST AI RMF
GOVERN 6.1 - Organizational risk policies and procedures MANAGE 2.2 - Risk response
OWASP LLM Top 10
LLM06 - Excessive Agency

Frequently Asked Questions

What is GHSA-48m6-ch88-55mj?

Flowise's registration endpoint fails to enforce an input allowlist, letting unauthenticated attackers inject server-managed fields — including organizationId and owner roleId — at account creation time, granting instant owner-level access to any existing tenant with a single crafted HTTP request. This is a severe trust boundary violation: Flowise deployments store embedded LLM API keys, workflow logic, and agent tool credentials scoped per organization, all of which are exposed once an attacker joins as owner. No public exploit code exists and active exploitation has not been confirmed, but the attack requires only knowledge of a target organization UUID — discoverable through prior API interaction, error messages, or enumeration — making this trivially weaponizable post-disclosure. Upgrade to Flowise 3.1.0 immediately; if patching is delayed, block the /api/v1/account/register endpoint at the WAF or network layer and audit existing accounts for unexpected organization associations or anomalous createdBy timestamps.

Is GHSA-48m6-ch88-55mj actively exploited?

No confirmed active exploitation of GHSA-48m6-ch88-55mj has been reported, but organizations should still patch proactively.

How to fix GHSA-48m6-ch88-55mj?

1. Patch: Upgrade to Flowise 3.1.0 which enforces DTO-based validation on the registration endpoint. 2. Immediate workaround: Disable public registration or restrict /api/v1/account/register to trusted IP ranges via WAF or reverse proxy rules. 3. Detection: Audit the accounts table for entries where createdBy/updatedBy fields contain UUIDs not matching the created user, or where organizationUser records were created at the same timestamp as account registration. 4. Incident response: Review registration logs for payloads containing 'organization', 'organizationUser', or 'workspaceUser' keys outside the standard schema. 5. Rotate any LLM provider API keys stored in affected Flowise organizations as a precaution.

What systems are affected by GHSA-48m6-ch88-55mj?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI workflow platforms, multi-tenant LLM application builders, LLM API credential stores.

What is the CVSS score for GHSA-48m6-ch88-55mj?

GHSA-48m6-ch88-55mj has a CVSS v3.1 base score of 8.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI workflow platformsmulti-tenant LLM application buildersLLM API credential stores

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0021 Establish Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0083 Credentials from AI Agent Configuration
AML.T0085 Data from AI Services

Compliance Controls Affected

EU AI Act: Article 15, Article 9
ISO 42001: A.6.1.2, A.8.4
NIST AI RMF: GOVERN 6.1, MANAGE 2.2
OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

### Summary An improper mass assignment (JSON injection) vulnerability in the account registration endpoint of Flowise Cloud allows unauthenticated attackers to inject server-managed fields and nested objects during account creation. This enables client-controlled manipulation of ownership metadata, timestamps, organization association, and role mappings, breaking trust boundaries in a multi-tenant environment. ### Details The POST /api/v1/account/register endpoint is intended to accept a minimal payload to create a new user account (e.g., name, email, password). However, the backend fails to enforce a strict allowlist or DTO-based validation and instead blindly maps client-supplied JSON to internal domain models. As a result, attackers can include additional nested objects and server-managed fields in the request body such as organization, organizationUser, workspace, workspaceUser, and metadata fields like createdBy, updatedBy, createdDate, and updatedDate. These fields are persisted as provided by the client rather than being generated or validated server-side. This behavior demonstrates a trust boundary violation where authorization and ownership decisions that must be enforced by the server are effectively delegated to untrusted client input. In a multi-tenant SaaS context, this can lead to unauthorized organization association and role assignment during registration. ### PoC Send a standard registration request: ```http POST /api/v1/account/register HTTP/2 Host: cloud.flowiseai.com Content-Type: application/json { "user": { "name": "Test User", "email": "testuser@example.com", "credential": "StrongPassword123!" } } ``` Observe the 201 Created response returning a newly created user and related objects (organization, workspace, roles). Send a modified registration request that injects additional server-managed fields and nested objects: POST /api/v1/account/register HTTP/2 Host: cloud.flowiseai.com Content-Type: application/json ```http { "user": { "name": "Injected User", "email": "injected@example.com", "credential": "StrongPassword123!", "createdBy": "<arbitrary-uuid>", "updatedBy": "<arbitrary-uuid>", "createdDate": "1999-12-27T13:10:47.666Z", "updatedDate": "1999-12-27T13:10:47.666Z" }, "organization": { "id": "<existing-organization-uuid>", "name": "Injected Organization" }, "organizationUser": { "organizationId": "<existing-organization-uuid>", "roleId": "<owner-role-uuid>" } } ``` Observe that the server responds with 201 Created and persists the injected fields, reflecting client-controlled values for ownership metadata, timestamps, and organization association. ### Impact - Vulnerability Class: Mass Assignment / JSON Injection / Improper Input Validation. - Who is impacted: All deployments of Flowise Cloud exposing the registration endpoint. By supplying a known organizationId during registration, an unauthenticated attacker can create a new user account directly associated with an existing organization they do not belong to. This results in unauthorized cross-tenant access and privilege escalation at account creation time, completely bypassing organizational ownership and trust boundaries. **Security Consequences**: 1. Client-controlled manipulation of server-managed fields (audit timestamps, ownership metadata). 2. Unauthorized association of newly created accounts with existing organizations. 3. Injection of role and membership relationships during registration. 4. Violation of trust boundaries in a multi-tenant environment, increasing the risk of privilege abuse and audit integrity failures.

Exploitation Scenario

An attacker targeting a competitor's Flowise-backed AI automation platform first enumerates an organization UUID by registering a legitimate account and observing the UUID returned in the 201 response for their own organization. Using that UUID pattern, they identify or guess target organization UUIDs. The attacker then sends a crafted POST to /api/v1/account/register with the target organizationId and an owner roleId injected alongside normal registration fields. The server responds with 201 Created and persists the attacker's account with owner-level membership in the victim organization. The attacker logs in, accesses the victim's AI agent configurations, extracts embedded OpenAI or Anthropic API keys, exfiltrates proprietary workflow logic, and potentially modifies agents to exfiltrate future user data processed through the platform.

Weaknesses (CWE)

CWE-20 — Improper Input Validation: The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

  • [Architecture and Design] Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of allowing parser code to be scattered throughout the program, where it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110] [REF-1111]
  • [Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
April 16, 2026
Last Modified
April 16, 2026
First Seen
April 17, 2026

Related Vulnerabilities