CVE-2026-100607: Flowise Authentication Bypass Vulnerability

CVE-2026-100607 Overview

CVE-2026-100607 is an authentication bypass vulnerability in Flowise through version 3.1.4. The application resolves both Single Sign-On (SSO) and local-password users solely by email address. Flowise does not store provider or subject identifier bindings for authenticated users. Attackers can authenticate as any existing user by claiming the victim's email at any configured SSO provider. Successful exploitation grants complete account access, including chatflows, stored credentials, and API keys. The flaw is tracked under CWE-287 Improper Authentication and affects the Flowise low-code LLM orchestration platform maintained by FlowiseAI.

Critical Impact
Attackers can take over any Flowise account by signing in through a different SSO provider or local password than the victim's original registration method.

Affected Products

Flowise versions up to and including 3.1.4
FlowiseAI Flowise deployments configured with one or more SSO providers
Flowise instances with mixed local-password and SSO authentication enabled

Discovery Timeline

2026-09-26 - CVE-2026-100607 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-100607

Vulnerability Analysis

Flowise supports multiple authentication methods including local username and password login along with federated SSO providers. The application uses the email address returned by the authentication provider as the sole lookup key when resolving a user record. The authentication layer does not persist a binding between a user account and the originating identity provider or the provider-specific subject identifier (sub claim). Any identity source that returns a matching email is treated as the owner of that account.

This design collapses distinct identity namespaces into a single email-keyed namespace. A victim who registered using local credentials can be impersonated by an attacker who controls or configures an SSO account that asserts the same email. The impact extends beyond session access because Flowise stores API keys, credentials for downstream services, and chatflow definitions tied to each account.

Root Cause

The root cause is missing identity provider binding during user resolution. Secure authentication requires a composite key of (provider, subject) rather than email alone, since email claims are not globally unique across identity providers and are not always verified. Flowise through 3.1.4 omits this binding and trusts the email claim from any configured provider.

Attack Vector

The vulnerability is exploitable over the network without prior authentication or user interaction. An attacker enumerates or guesses a target email address associated with an existing Flowise account. The attacker then authenticates to a configured SSO provider using an identity that asserts the victim's email, or submits a local password reset flow where applicable. The Flowise backend matches the email to the existing user record and issues a session for the victim's account. Full technical details are available in the GitHub Security Advisory GHSA-cffm-583c-vffr and the VulnCheck Advisory on Flowise Authentication Bypass.

Detection Methods for CVE-2026-100607

Indicators of Compromise

Successful SSO logins for a user account from a provider that differs from the account's original registration method.
New or unexpected API key creation events immediately following an SSO login event.
Access to chatflows or stored credentials from source IP addresses or geolocations inconsistent with the user's baseline.
Audit log entries showing authentication events for the same email from multiple distinct identity providers within a short interval.

Detection Strategies

Correlate authentication events by email across all configured SSO providers and local login endpoints, flagging accounts authenticated through more than one provider.
Review Flowise application logs for user resolution events that match an email to a user record without a corresponding provider identifier check.
Alert on first-time use of an SSO provider for an account previously tied to local-password authentication.

Monitoring Recommendations

Forward Flowise authentication, API key, and credential access logs to a centralized logging platform for correlation and retention.
Baseline each user's expected identity provider and alert on deviations.
Monitor downstream services that accept Flowise-issued API keys for unexpected request patterns originating from compromised accounts.

How to Mitigate CVE-2026-100607

Immediate Actions Required

Upgrade Flowise to a version later than 3.1.4 that enforces provider and subject identifier binding during authentication.
Rotate all Flowise-managed API keys and credentials for downstream services, since existing secrets may already be exposed.
Audit all user accounts and recent authentication events for signs of unauthorized access through alternate providers.
Restrict Flowise administrative interfaces to trusted networks until patching is complete.

Patch Information

Refer to the GitHub Security Advisory GHSA-cffm-583c-vffr for the fixed version and upgrade guidance. The remediation introduces persistent bindings between user accounts and the originating identity provider plus subject identifier, so authentication requests from a different provider no longer resolve to the existing account.

Workarounds

Disable all but one authentication method on affected Flowise deployments to collapse the attack surface to a single trusted identity source.
Where SSO is required, restrict configured providers to a single enterprise identity provider with verified email claims.
Place Flowise behind a reverse proxy that enforces an additional authentication layer, such as mutual TLS or an identity-aware proxy, until the patch is applied.

bash

# Example: restrict Flowise to a single SSO provider by removing other providers
# from the environment configuration before restarting the service
unset FLOWISE_LOCAL_AUTH_ENABLED
unset FLOWISE_SSO_GITHUB_CLIENT_ID
unset FLOWISE_SSO_GOOGLE_CLIENT_ID
export FLOWISE_SSO_AZURE_CLIENT_ID="<trusted-provider-client-id>"
systemctl restart flowise