Flowise EUVD-2026-87702

Exploitation requires the Flowise deployment (through 3.1.4) to have at least one SSO provider configured, since users are resolved solely by email with no stored provider or subject-identifier binding; the attacker must know a victim's registered email and be able to assert that email as their identity at any configured SSO provider (or via the local-password path). This is the AT:P attack requirement in the vendor vector. No authentication as the victim is needed (PR:N) and no victim interaction is required (UI:N). The primary limiting factor is that SSO must be enabled and the attacker must control or use an SSO provider that lets them present the victim's email; instances with SSO disabled are not exposed to the cross-provider claim path.

This is a genuine, high-priority authentication bypass (CWE-287), not a high-CVSS-but-low-real-risk paper cut. The vendor CVSS 4.0 vector (9.2, AV:N/AC:L/PR:N/UI:N/VC:H/VI:H/VA:L) describes remote, unauthenticated, no-interaction exploitation yielding high confidentiality and integrity impact - consistent with the description's claim of complete account takeover (chatflows, stored credentials, API keys). The single mitigating CVSS signal is AT:P (a specific attack requirement), which maps to the real-world prerequisite that the deployment has at least one SSO provider configured and the attacker can assert the victim's email at it. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - this tempers immediacy but does not lower the design-flaw severity, since the bypass is architectural (identity resolved by email alone with no provider/subject binding) and conceptually trivial to reproduce once SSO is enabled. No conflicting signals were found: the network vector and unauthenticated access in the CVSS vector align with the description. The 'Authentication Bypass' tag is accurate here (unlike sibling authorization-flaw CVEs in the same product), because the root cause is broken identity verification.

An attacker targets a Flowise instance (through 3.1.4) that has SSO enabled, learns a victim admin's registered email address, and logs in through any configured SSO provider (or the local-password path) asserting that same email. Because Flowise matches users by email only and never binds the account to the original provider or subject identifier, the attacker is authenticated as the victim and inherits full access to their chatflows, stored credentials, and API keys. No public proof-of-concept is identified in the provided data, but the flaw is architecturally simple to trigger.