GHSA-48m6-ch88-55mj: Flowise: Mass Assignment allows cross-tenant org takeover
GHSA-48m6-ch88-55mj HIGHFlowise'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.
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?
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?
What is the attack surface?
What should I do?
5 steps-
Patch: Upgrade to Flowise 3.1.0 which enforces DTO-based validation on the registration endpoint.
-
Immediate workaround: Disable public registration or restrict /api/v1/account/register to trusted IP ranges via WAF or reverse proxy rules.
-
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.
-
Incident response: Review registration logs for payloads containing 'organization', 'organizationUser', or 'workspaceUser' keys outside the standard schema.
-
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:
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
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
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
Primary
CWE-639 Authorization Bypass Through User-Controlled Key
Primary
CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes
Primary
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 References
Timeline
Related Vulnerabilities
CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same package: flowise CVE-2026-46442 9.9 Flowise: sandbox escape enables authenticated RCE
Same package: flowise CVE-2025-61913 9.9 Flowise: path traversal in file tools leads to RCE
Same package: flowise CVE-2026-40933 9.9 Flowise: RCE via MCP stdio command injection
Same package: flowise CVE-2026-56274 9.9 Flowise: RCE via MCP server command validation bypass
Same package: flowise