CVE-2026-100607 in Flowise
Summary
by MITRE • 09/26/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Flowise versions prior to 3.1.4 represents a critical authentication logic flaw rooted in an oversimplified user resolution strategy. The core technical deficiency lies in how the application maps external identity assertions to internal user accounts. Specifically, the system relies exclusively on the email address as the unique identifier for linking SSO sessions and local password-based accounts. This design choice ignores standard identity federation practices which typically require binding a specific combination of provider identifiers, such as the OpenID Connect issuer or subject ID, alongside the email claim. By failing to store these provider-specific bindings, the application treats an email address as a universal key that is agnostic to its source. Consequently, if multiple SSO providers are configured within the same Flowise instance, any user who can control an account at one of those identity providers and possesses an email address matching an existing local or SSO user in Flowise can successfully authenticate into that target account.
This architectural weakness facilitates a severe form of account takeover where attackers do not need to compromise the victim's credentials directly. Instead, they exploit the trust relationship between Flowise and its configured Identity Providers. An attacker who registers for a service at any enabled SSO provider with an email address identical to a high-privilege user in Flowise can initiate an authentication flow through that specific provider. Because Flowise resolves users solely by email without verifying which identity provider originally created or owns the account, it accepts this new assertion as valid and logs the attacker into the victim's session. This bypasses all security controls associated with the original registration method, whether that was a local password hash or an authentication via a different SSO provider entirely. The result is complete unauthorized access to the user's environment without any need for credential stuffing or phishing attacks targeting the specific identity source.
The operational impact of this vulnerability is extensive and potentially catastrophic depending on the sensitivity of data managed within Flowise. Once authenticated, the attacker gains full administrative control over the compromised account. This includes unrestricted access to chatflows, which may contain proprietary business logic, prompt engineering strategies, or sensitive conversational histories. More critically, attackers can view and export stored credentials, API keys, and database connection strings that users have configured for their AI agents and integrations. These secrets often provide lateral movement opportunities into downstream systems such as cloud infrastructure, internal databases, or third-party APIs. The ability to impersonate any user also undermines audit trails and accountability, making it difficult to distinguish between legitimate actions taken by the account owner and malicious activities performed by an attacker who has hijacked the identity through email matching.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication, specifically regarding the failure to verify unique identifiers across different authentication contexts. It also reflects weaknesses associated with CWE-613 Insufficient Session Expiration and CWE-598 Use of GET Request Method if session tokens are exposed during the SSO redirect flow, though the primary flaw is logical rather than transport-based. In terms of MITRE ATT&CK framework tactics, this vulnerability enables Initial Access through Tactic TA0001 via exploitation of authentication mechanisms, specifically leveraging Identity Bridging or Account Manipulation techniques where an attacker leverages a trusted identity provider to gain entry into a target system without direct credential compromise. The attack path is consistent with lateral movement scenarios if the compromised account has permissions across multiple services within the organization's ecosystem.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. For organizations running Flowise versions earlier than 3.1.4, upgrading to version 3.1.4 or later is the primary corrective action as it resolves this specific logic error by implementing proper provider binding. In environments where an upgrade is not immediately feasible, administrators should consider disabling SSO providers that are not strictly necessary for business operations to reduce the attack surface. Additionally, enforcing strict email domain restrictions can limit the pool of external identity providers available for authentication, thereby reducing the likelihood of accidental or malicious email collisions between internal users and external attacker-controlled accounts. Long-term architectural reviews should prioritize implementing unique user identifiers derived from both the email claim and the specific SSO provider's subject ID to ensure that account resolution is deterministic and resistant to cross-provider impersonation attacks.