Description

Flowise through 3.1.4 (Enterprise/platform mode with SSO enabled) contains an authentication bypass in the SSO login path. When an SSO callback arrives with an email matching a user whose status is INVITED, verifyAndLogin (SSOBase.ts:80-94) copies the user record from the database — including the server-stored single-use invitation tempToken — into the data passed to AccountService.register(). The register handler's token lookup, email match, and expiry checks therefore pass trivially against the server's own token instead of a caller-supplied one, and the account and its organization membership are flipped to ACTIVE. As a result, anyone able to authenticate at any configured SSO provider using a pending invitee's email address as the email claim can take over that invitation and obtain the invited user's access to the organization without ever possessing the emailed invitation token, for as long as the invitation is valid (24 hours by default). At the time of the advisory no patched version was available.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-26T14:16:40.820Z",
  "pubdate": "2026-09-26T14:16:40.820Z",
  "executiveSummary": "A critical authentication bypass vulnerability exists in Flowise versions up to 3.1.4 when deployed in Enterprise or platform mode with SSO enabled.\nThe vulnerability occurs within the SSO callback handling logic, specifically in the verifyAndLogin function.\nAn attacker can hijack an existing 'INVITED' user's account by authenticating through an SSO provider using the target's email address.\nThis flaw allows unauthorized access to an organization's resources without requiring possession of the unique, single-use invitation token sent to the victim.\nThe vulnerability effectively permits account takeover for any pending invitee for the duration of the invitation's validity period (defaulting to 24 hours).\nThis represents a high-risk security flaw that compromises the integrity of the invitation workflow and potentially provides unauthorized access to sensitive platform data.\nExploitation requires only that the attacker possesses the ability to authenticate at an SSO provider and identifies an email address associated with a pending invitation on the Flowise platform.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper processing of user data during the SSO authentication callback sequence within SSOBase.ts.\nWhen an SSO callback is processed for a user with an 'INVITED' status, the verifyAndLogin function (lines 80-94) retrieves the existing user record from the database.\nCritically, this record includes the internal, server-stored single-use invitation tempToken. This sensitive data is then passed directly into the AccountService.register() method.\nIn the context of the register handler, the system performs a token lookup and validation logic intended to verify a user's entitlement to register.\nBecause the system inadvertently supplies the server's own stored tempToken to the registration logic instead of requiring the caller to provide a valid token, the registration checks resolve affirmatively.\nThe application erroneously treats the SSO authentication as a legitimate completion of the invitation process, resulting in the user's account status being updated from 'INVITED' to 'ACTIVE'.\nThe exploitation flow proceeds as follows: 1) An attacker identifies or anticipates an email address that currently possesses an 'INVITED' status within the target Flowise instance. 2) The attacker initiates an SSO login process using the target email address at an SSO provider trusted by the platform. 3) Upon receiving the callback, the Flowise platform triggers verifyAndLogin, which extracts the 'INVITED' user record and its associated tempToken. 4) The platform inadvertently bypasses the requirement for an externally provided token, as the internal token matches the record, causing the account activation to trigger automatically. 5) The attacker gains full access to the victim's account, including associated organizational memberships and permissions.\nThis vulnerability highlights a critical failure in the separation of authentication (SSO) and authorization (invitation validation) flows, where internal record state is leveraged to satisfy security constraints that were designed to validate external user-provided inputs."
}