Flowise CVE-2026-41267

Exploitation targets the unauthenticated POST /api/v1/account/register endpoint of a Flowise deployment running in multi-tenant mode (Flowise Cloud) on a version below 3.1.0. The concrete prerequisite that LIMITS exploitation is that the attacker must supply a valid, existing organization UUID (and corresponding role UUID) to hijack a specific tenant - arbitrary self-elevation without knowing these identifiers yields only a self-owned org, which is why the vendor rates AC:H. No authentication or user interaction is required (CVSS PR:N/UI:N), but the impact is meaningful only where the multi-tenant organization/workspace model is in use; a purely single-tenant self-hosted instance has a much smaller trust boundary to violate.

Signals are mixed and point to a serious-but-not-yet-mass-exploited flaw. The vendor CVSS of 8.1 (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H) reflects network reach and no authentication, but with high attack complexity - consistent with the PoC requirement that an attacker know a valid, existing organization UUID to hijack it. CISA SSVC rates Exploitation as 'poc', Automatable 'no', and Technical Impact 'total', which aligns with a targeted rather than spray-and-pray threat. EPSS is very low (0.04% / 13th percentile) and the CVE is not in CISA KEV, so there is no evidence of active exploitation despite a published PoC - do not conflate the two. The A:H (availability) component in the vendor vector is questionable: the described impact is integrity/authorization manipulation, and availability loss would only be an indirect consequence of gaining an owner role, so treat A:H as generous. Bottom line: for anyone running Flowise multi-tenant / Cloud this is a real priority because the technical impact is total tenant-boundary compromise; for single-tenant self-hosted instances the practical risk is lower.

An attacker first obtains a valid organization UUID (e.g., leaked in a URL, invite link, or prior response) belonging to a target tenant. They then POST a registration request to /api/v1/account/register containing the normal user fields plus injected organization and organizationUser objects referencing that UUID with an owner roleId, and the server persists the account already associated with the victim's organization at an elevated role. A working PoC demonstrating the 201 Created behavior and the injected-field request is published in the GitHub Security Advisory.