Summary
Flowise resolves SSO and local-password accounts using email addresses without binding each account to its original identity provider and subject identifier. An attacker who can authenticate through another configured SSO provider or authentication method while claiming an existing user's email may gain access to that user's account and stored resources.
Affected context
This issue occurs in Flowise deployments that support SSO and local-password authentication while identifying users solely by email address. Risk is present when multiple authentication methods or identity providers are configured and the application does not preserve and verify the provider-specific subject identifier associated with an account.
Exploit preconditions
- Attack surface: Flowise authentication and account-resolution logic
- Required access: A valid identity at a configured SSO provider or another accepted authentication method
- Trigger point: Authentication of a user whose claimed email matches an existing Flowise account
- Why exploitation is possible: The application treats the email address as sufficient identity proof instead of validating the original provider and subject binding
Why this happens
The underlying bug is an account-identity binding failure. Authentication results from different providers and methods are correlated solely by a user-controlled or provider-asserted email address, without requiring a stable provider-specific subject identifier and authentication-context match. This behavior maps to CWE-287: Improper Authentication, because the application does not adequately verify that the authenticated identity corresponds to the account being accessed.
Potential impact
- An attacker may take over an existing Flowise account
- Unauthorized users could access private chatflows and configuration data
- Stored credentials and API keys could be exposed or misused
- Attackers could modify workflows, integrations, or other account-owned resources
- Compromised accounts could be used to affect connected services
General mitigation guidance
Mitigation generally focuses on strong, provider-aware account identity binding rather than email-only matching.
Common defensive patterns include:
- Binding accounts to an immutable provider identifier and subject claim
- Treating email addresses as attributes rather than sufficient authentication keys
- Requiring deliberate, separately authenticated account-linking flows
- Preventing automatic cross-provider account merges unless explicitly confirmed
- Applying least privilege to stored credentials, API keys, and connected integrations
- Providing session invalidation, credential rotation, and account-recovery controls after identity changes
These patterns reduce the risk of authentication confusion while limiting the impact of any compromised account.
How teams detect issues like this
Organizations can look for authentication and account-linking weaknesses through:
- Static analysis and code review searches for account lookup by email without provider and subject checks
- Tests that use identical email addresses across different identity providers and authentication methods
- Review of OAuth or SSO callback handling for missing issuer, provider, or subject validation
- Monitoring for unexpected provider changes, new sessions, credential access, and API-key use
- Policy enforcement requiring explicit approval for account merges and identity changes
Automated security testing and code review tools may help identify email-only identity correlation.
