Summary
Flowise contains an authentication bypass in its SSO login flow when an SSO identity matches a user with an outstanding invitation. The application may trust a server-stored invitation token during registration, allowing an attacker authenticated through a configured SSO provider with the invitee's email claim to activate the account without possessing the emailed invitation token.
Affected context
The issue affects Flowise deployments using Enterprise or platform mode with SSO enabled. It occurs when the SSO callback identifies an account whose status is INVITED and the invitation remains valid, allowing the login and registration paths to process the pending invitation as though its token had been supplied by the user.
Exploit preconditions
- Attack surface: SSO authentication and callback handling
- Required access: Ability to authenticate at a configured SSO provider using an identity whose email claim matches a pending invitee
- Trigger point: Processing of the SSO callback and subsequent account registration
- Additional condition: The target invitation must remain valid and associated with an INVITED account
- Why exploitation is possible: The login flow copies the invited user's server-stored temporary token into registration data, allowing token lookup, email matching, and expiry checks to succeed without independently validating possession of the emailed invitation token
Why this happens
The underlying flaw is a failure to preserve the trust boundary between server-side invitation state and caller-provided authentication data. During SSO processing, the application passes the invited user's stored temporary token into the registration workflow, where validation treats that value as if it had been presented by the caller. This maps to CWE-287: Improper Authentication, because possession of the invitation credential is not independently established before the account and organization membership are activated.
Potential impact
- An attacker may activate a pending invitation without possessing its emailed token
- The attacker could obtain the invited user's access to the organization
- Organization data and resources may be accessed or modified
- Account ownership and membership state could be changed during the invitation validity period
General mitigation guidance
Mitigation generally focuses on ensuring that invitation credentials are independently presented and verified rather than copied from server-side account records.
Common defensive patterns include:
- Require the invitation token to originate from the intended invitation flow and validate it independently of SSO claims
- Avoid treating database-held secrets as proof of caller possession
- Bind invitations to verified identities and enforce one-time consumption semantics
- Keep account activation and organization membership changes behind explicit authentication and authorization checks
- Apply least privilege to invited accounts until activation is completed
- Use secure-by-default SSO policies that do not automatically activate pending accounts solely from an email claim
How teams detect issues like this
Organizations can assess for this weakness through:
- Static analysis and code review of SSO callback handlers for server-side tokens copied into authentication or registration requests
- Tests verifying that pending invitations cannot be activated without an independently supplied invitation credential
- Review of account-state transitions from INVITED to ACTIVE and related organization membership changes
- Monitoring for SSO logins that immediately activate invitations without a corresponding invitation-token validation event
- Policy checks requiring separate evidence of possession for invitation-based account activation
Automated security review tools may help identify authentication data-flow issues, but behavioral tests are important for confirming the trust-boundary violation.
