CVE-2026-100607

Executive Summary

CVE-2026-100607 is an improper authentication vulnerability (CWE-287) in Flowise, an open-source low-code platform for building LLM applications and AI agents. The platform resolves both SSO and local-password logins solely by email address, without storing provider or subject identifier bindings, allowing an attacker to authenticate as any existing user by presenting that user's email at any configured SSO provider or via the local password path. Successful exploitation grants complete account takeover, exposing chatflows, stored credentials, and API keys, with a CVSS base score of 7.7.

Technical Analysis

The vulnerability is rooted in a flawed identity-binding design within Flowise's authentication layer. Under a correct federated identity implementation, a user account should be bound to the specific identity provider and the immutable subject identifier (the sub claim in OpenID Connect, or the equivalent stable user ID in SAML) asserted by that provider at registration time. CVE-2026-100607 describes the opposite behavior: Flowise, through version 3.1.4, "resolves SSO and local-password users solely by email without storing provider or subject identifier bindings."

This produces two distinct but related failure modes:

1. Cross-provider impersonation. If an organization has configured more than one SSO provider (for example, a corporate IdP and a secondary provider such as a social or third-party identity service), an attacker who can obtain a valid identity at any configured provider can claim the victim's email address there. Flowise then resolves that inbound assertion to the existing victim account based purely on the email string. The provider binding that would normally prevent this is never stored or checked.

2. Local-password bypass of SSO-origin accounts. Because the platform does not record that a given user was originally registered through SSO, the same email-based resolution logic allows the local password authentication path to match an SSO-provisioned account. An attacker who controls a local account, or who can trigger or abuse the local password flow for the victim's email, can be resolved into the victim's account despite the victim never having used a local password.

From an access-control model perspective, the email address is treated as a globally unique, trustworthy, and stable principal identifier. In practice, email addresses are neither guaranteed unique across identity providers nor inherently verified and controlled exclusively by the legitimate account holder. The absence of an (identity_provider, subject_identifier) composite binding — and the absence of any enforcement that the authenticating mechanism matches the registration mechanism — collapses multiple distinct authentication paths onto a single spoofable key. This is a classic authentication-design flaw rather than a memory-safety or injection bug; it requires no payload crafting and no code execution. The attack surface is the authentication endpoint(s) that accept SSO callbacks and local credential submissions, reachable over the network (AV:N).

Notably, the CVSS vector reflects a high attack complexity (AC:H). This is consistent with the need for the attacker to obtain a valid assertion from a configured provider while asserting the target email — a precondition that is not universally satisfiable, which is why the flaw is scored 7.7 rather than critical. Confidentiality and integrity impacts are rated High, reflecting full access to chatflows, credentials, and API keys; availability is rated Low.

No public proof-of-concept, exploit code, or Nuclei template is known to exist at the time of writing. The mechanism described above is derived strictly from the NVD description; specific function names, endpoints, and parameter names are not disclosed in the available data and are therefore not asserted here.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (improper authentication / broken identity binding) and the NVD description.

1. Reconnaissance / target identification. The attacker identifies an internet- or intranet-exposed Flowise instance running version 3.1.4 or earlier. Fingerprinting can be performed via Shodan using the platform's application title, favicon hash, or HTML markers, or by directly probing the login/SSO entry points. The attacker then enumerates the configured sign-in options (for example, which SSO providers are offered) and acquires a target email address — such as an administrator's or a developer-with-API-keys' address — through OSINT, organizational directory leakage, or error messages.

2. Triggering the flaw. The attacker authenticates against one of the configured SSO providers (or via the local password path) using an identity whose email address equals the victim's. The critical precondition is that the attacker can present a valid identity assertion bearing the victim's email. Because Flowise does not store or validate a provider/subject binding, the authentication layer resolves the inbound email to the existing victim account instead of rejecting the mismatch of provider or credential type.

3. Execution / authentication. No injection payload or file is required. The "exploit" is simply a successful login: the platform issues a session or token scoped to the victim's account because the email key matched, regardless of which mechanism the victim originally registered with. This is the essence of the CWE-287 weakness — authentication succeeds for the wrong principal.

4. Post-exploitation impact. With the victim's account context, the attacker gains full access to that user's resources: chatflows (including embedded logic and any secrets referenced by them), stored credentials, and API keys. From here, an attacker would typically harvest the exposed API keys and credentials for downstream abuse — moving into connected LLM providers, databases, or SaaS integrations configured in Flowise. These credentials can be exfiltrated and used outside the platform, or used to modify chatflows to inject malicious behavior into automated AI workflows, establishing persistence and enabling supply-chain-style abuse of any downstream consumers of the victim's flows.

The absence of published exploit tooling means exploitation currently requires manual, targeted effort, but the mechanism itself involves no cryptographic barrier once the email-claiming precondition is met.

Impact Assessment

Impact is significant for any organization exposing Flowise with more than one configured authentication path, and severe where privileged accounts (administrators, integration owners) are provisioned via a provider that an attacker can also obtain an identity on.

• Confidentiality (C:H). Full read access to chatflows, stored credentials, and API keys associated with the impersonated account. Because Flowise flows frequently embed external service credentials, this can lead to the compromise of third-party systems beyond the platform itself.
• Integrity (I:H). The attacker can modify chatflows, rotate or replace stored credentials and API keys, and alter the behavior of automated AI pipelines, potentially affecting downstream data and services.
• Availability (A:L). Limited availability impact — disruption is possible (for example, by breaking flows or rotating keys) but is not the primary objective and is bounded.
• Attack Vector (AV:N) / Privileges Required (PR:N) / User Interaction (UI:N). No prior privileges and no victim interaction are needed; the attacker authenticates directly. The only gating factor is attack complexity (AC:H), reflecting the requirement to obtain a valid assertion bearing the target's email at a configured provider.

Blast radius. Any user whose email can be claimed at a reachable configured provider is at risk, with administrative and integration-owning accounts being the highest-value targets. Secondary blast radius extends to any external system whose API keys or credentials are stored in, or referenced by, affected chatflows. Organizations relying on a single SSO provider that they fully control and that does not permit arbitrary email assertion may face reduced exposure, but the local-password path coupling described in the advisory widens the practical risk surface.

As of this assessment, CISA KEV status is NO, there is no evidence of in-the-wild exploitation, and no EPSS score has been published by FIRST.org (EPSS is not yet scored). The overall risk should be treated as elevated for exposed instances because exploitation, once the email precondition is met, is straightforward and leaves minimal footprint.

Detection Guidance

Detection should focus on anomalies in authentication events: logins succeeding through a provider or mechanism that differs from a user's historical/registered method, email-to-account resolution for SSO callbacks, and sudden first-time logins from new IPs/ASNs followed by access to chatflows, credentials, or API-key endpoints. The signatures below are generic to the vulnerability class and should be tuned to your Flowise deployment's actual logging.

Sigma Rule

title: Flowise Potentially Anomalous SSO/Local Authentication via Email-Only Identity Resolution
id: 3f2a9c1e-7b64-4d21-9a0e-100607cve00
status: experimental
description: Detects successful Flowise authentications where the identity provider or credential type differs from expected, consistent with CVE-2026-100607 email-based account takeover.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-100607
author: valtersit.com
date: 2026/01/01
logsource:
  product: flowise
  service: authentication
detection:
  selection_success:
    event:
      - 'login.success'
      - 'auth.success'
      - 'sso.callback.success'
  selection_sso_resolve:
    message|contains:
      - 'sso'
      - 'email'
      - 'provider'
  condition: selection_success and selection_sso_resolve
falsepositives:
  - Legitimate first-time SSO logins
  - Users switching between SSO and local password by design
level: medium
tags:
  - attack.t1078.004
  - attack.initial_access
  - cve.2026-100607

YARA Rule

rule CVE_2026_100607_Flowise_Auth_Email_Binding
{
    meta:
        description = "Detects Flowise source/config artifacts lacking provider or subject identifier bindings in authentication logic (CVE-2026-100607)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100607"
        date = "2026-01-01"
        severity = "high"

    strings:
        $a = "flowise" nocase
        $b = "sso" nocase
        $c = "email" nocase
        $d = "provider" nocase
        $e = "subject" nocase
        $f = "identityProvider" nocase

    condition:
        $a and $b and $c and (1 of ($d, $e, $f))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-100607 Flowise SSO Authentication Attempt With Identity Claim"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"sso"; nocase; http.uri; content:"callback"; nocase; http.header; content:"email"; nocase; threshold:type limit, track by_src, count 5, seconds 60; classtype:attempted-user; reference:cve,2026-100607; sid:2026100607; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ authentication where event.action == "login" and event.outcome == "failure" ]
  [ authentication where event.action == "login" and event.outcome == "success" and
      (user.email != null or process.name : "flowise*") ]

Splunk SPL Query

index=flowise sourcetype=flowise:auth ("sso" OR "email" OR "provider")
| eval auth_method=coalesce(sso_provider, auth_type, "unknown")
| stats values(auth_method) as methods, dc(auth_method) as method_count,
        count by user_email, src_ip
| where method_count > 1 OR match(_raw, "(?i)sso.*callback")
| table _time user_email src_ip methods method_count

Wazuh OSSEC Rule

<group name="flowise,authentication,cve-2026-100607,">
  <rule id="100607" level="10">
    <decoded_as>json</decoded_as>
    <field name="event">login.success|sso.callback.success</field>
    <field name="message">email|sso|provider</field>
    <description>CVE-2026-100607: Flowise successful auth via email-only identity resolution (possible account takeover)</description>
    <mitre>
      <id>T1078.004</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence is 0/4 — UNPATCHED. No vendor patch, commit reference, or advisory covering a fix has been identified from any tracked source, and no workaround is documented. Treat all Flowise deployments at version 3.1.4 and earlier as vulnerable until a fix is released.

1. Immediate mitigations.

   • Remove Flowise instances from direct internet exposure; restrict access to trusted networks or place them behind an authenticating reverse proxy / VPN / zero-trust gateway.
   • Reduce the number of configured authentication paths. Where possible, disable secondary SSO providers and the local-password mechanism for accounts that should be SSO-only, so there is no alternate path through which an attacker could claim a victim's email.
   • Enforce at the identity provider that email assertions cannot be self-asserted or arbitrarily chosen — require verified email claims and disallow email mutation by users.
   • Audit existing accounts for duplicate or conflicting email addresses across providers, and reconcile them manually.
   • Rotate all API keys and stored credentials present in Flowise chatflows, since these are the highest-value assets exposed by successful impersonation; rotate preemptively if you cannot rule out prior exploitation.

2. Patch/upgrade steps.

   • Monitor the Flowise project's release channels and the NVD entry for CVE-2026-100607 for an official fix. No patched version exists at this time.
   • When a patch is released, upgrade immediately and verify that the fix introduces provider- and subject-identifier bindings (i.e., that accounts are keyed on (identity_provider, subject_identifier) rather than email alone) before relying on it.
   • After upgrading, force re-authentication for all users and re-review account-to-identity mappings.

3. Long-term hardening.

   • Adopt an identity model that binds accounts to immutable subject identifiers and the specific provider that issued them; never treat email as a globally unique credential.
   • Implement step-up verification (MFA) at every authentication path and require that the authenticating provider matches the account's registration provider.
   • Institute least-privilege scoping for API keys and credentials stored in chatflows, with routine rotation and vaulting rather than inline plaintext storage.
   • Centralize authentication logging and alerting on provider mismatch, first-seen login locations, and credential/API-key access anomalies.
   • Maintain an inventory of AI/LLM orchestration platforms (Flowise and similar) with version tracking, and include them in exposure-management and SSO governance reviews.
   • Monitor CISA KEV and vendor channels for exploitation updates; as of this writing there is no known in-the-wild activity.

References

• NVD — CVE-2026-100607: https://nvd.nist.gov/vuln/detail/CVE-2026-100607
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1078.004 — Valid Accounts: Cloud Accounts: https://attack.mitre.org/techniques/T1078/004/
• Flowise project (vendor source / release notes to monitor for a fix): https://github.com/FlowiseAI/Flowise
• CISA Known Exploited Vulnerabilities Catalog (status: not listed as of this report): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No public proof-of-concept, exploit code, or Nuclei template is known. No threat-actor campaign or exploit-in-the-wild evidence has been attributed to CVE-2026-100607 at the time of this assessment, and EPSS has not yet scored the vulnerability.