Description

Flowise through 3.1.4 resolves SSO and local-password users solely by email without storing provider or subject identifier bindings, allowing attackers to authenticate as any existing user by claiming their email at any configured SSO provider. Attackers can gain complete account access including chatflows, credentials, and API keys by authenticating through a different SSO provider or local password than the victim's original registration method.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-26T14:16:40.983Z",
  "pubdate": "2026-09-26T14:16:40.983Z",
  "executiveSummary": "Flowise versions up to 3.1.4 contain a critical authentication vulnerability arising from improper identity verification logic. The application fails to strictly bind users to specific authentication providers or subject identifiers, relying exclusively on the email address provided during the authentication process.\nThis design flaw allows an attacker to perform account takeover against any existing user within the Flowise instance. By leveraging an alternative SSO provider or the local password authentication mechanism, an attacker can authenticate as a victim by simply possessing or claiming the victim's email address. The vulnerability permits unauthorized access to sensitive administrative resources, including managed chatflows, stored environment credentials, and API keys.\nThe risk implication is severe, as it facilitates full lateral movement and persistence within the application environment. Attackers require no prior credentials for the victim's original account, only the ability to authenticate through a provider recognized by the Flowise installation. This issue represents a significant failure in the application's identity and access management architecture.",
  "technicalDetails": "The root cause of this vulnerability is an insecure authentication reconciliation mechanism that treats the email address as a globally unique and immutable identifier without enforcing provider-level context. In Flowise versions 3.1.4 and earlier, the backend logic identifies and authenticates users by querying the database for a matching email address, disregarding the underlying authentication method or the unique subject (sub) identifier issued by the identity provider.\nDuring a typical authentication flow, the application receives a user identity object from an SSO provider or a local login form. Rather than validating the security token or verifying that the authentication provider matches the user's initial registration method, the application performatively extracts the email address to retrieve the user's session record. This lack of binding between the user identity and the authentication source effectively creates an authentication collision.\nAn attacker can exploit this flaw by triggering an authentication request through a secondary SSO provider configured in the environment or by utilizing local-password authentication if the target user was initially registered via an external SSO. Because the application logic does not verify the provenance of the identity assertion, the attacker successfully impersonates the target user simply by providing an email that exists within the system's user database. Once the application completes the lookup, it grants a valid session token corresponding to the victim's account.\nThe exploitation process is as follows: 1) The attacker identifies a target email address registered in the Flowise instance. 2) The attacker initiates an authentication attempt using a different SSO provider (if available) or the standard local login flow. 3) The application’s authentication controller processes the email-based look-up and matches the attacker's input to the victim’s existing record. 4) The application issues an authenticated session, granting the attacker full control over the victim's workspace.\nThe impact of successful exploitation is total compromise of the user account. As Flowise functions as a orchestration engine for LLM workflows, gaining control over an account provides access to sensitive API keys, vector database connections, and internal chatflow logic. This enables an attacker to exfiltrate proprietary data, modify existing workflows to act as malicious proxies, or use stored credentials to access downstream infrastructure."
}