CVE-2026-100606: Flowise SSO Invite Takeover and IdP Checks

Last updated: September 2026

CVE-2026-100606 is an authentication bypass in Flowise Enterprise, the visual builder for LLM apps and AI agents, in every version up to and including 3.1.4 when SSO is enabled. If a user has a pending invitation, anyone who can sign in at one of the configured SSO providers with that invitee’s email address takes over the invitation and joins the organisation, without ever seeing the invitation link. VulnCheck published the CVE on 26 September 2026 with a CVSS 4.0 score of 9.2 (Critical) and a CVSS 3.1 score of 7.7 (High), which is the number many scanners will show. A fix was merged into Flowise’s main branch on 31 July 2026, but no tagged release carries it and the repository has since been archived. The practical defence is to remove pending invitations while SSO is on, and to make sure every SSO provider only asserts email addresses it has verified.

This is not an identity provider bug, because the flaw is in how Flowise decides that an SSO login completes an invitation. The identity provider does decide who can present a given email address, so the IdP configuration is what determines how many people could exploit it. This post explains the mechanism from the Flowise source, which providers widen the exposure, and the checks that apply to any app that mixes email invitations with single sign-on, including apps you build on Keycloak.

How does CVE-2026-100606 work?

The CVE record describes the problem precisely. When an SSO callback arrives with an email that matches a user whose status is INVITED, Flowise’s verifyAndLogin copies the stored user record, including the server-side single-use invitation tempToken, into the data it passes to AccountService.register(). The registration handler then checks the token, the email and the expiry “against the server’s own token instead of a caller-supplied one”, so every check passes and the account and its organisation membership are set to ACTIVE (CVE Program, CVE-2026-100606, 2026).

We read the code at the [email protected] tag to confirm it. In SSOBase.ts, the INVITED branch builds the registration payload with ...user, which spreads every column of the stored user record, tempToken included. In account.service.ts, the Enterprise branch of register() looks the user up by data.user.tempToken, compares the email, checks the expiry, and then activates the user with the MEMBER role. The invitation token was meant to prove that the person clicking the link had received the invitation email. Because the server supplied its own copy of the token, that proof was never required.

What the attacker needs

The attacker needs three things. The target Flowise instance must run in Enterprise mode with at least one SSO provider configured. There must be a pending invitation for some email address. And the attacker must be able to complete a login at one of the configured providers that reports that email address. The window is the invitation’s lifetime, which the CVE record gives as 24 hours by default; in the source it comes from the INVITE_TOKEN_EXPIRY_IN_HOURS environment variable.

The result is the access the invited user would have had: an active account with the MEMBER role in the inviting organisation, including its workspaces, chatflows and whatever credentials those flows can reach.

Why is this not the identity provider’s fault?

An SSO login proves that the identity provider vouches for an email claim. An invitation link proves that someone could read the mailbox the invitation was sent to. Those are different facts, and the Flowise maintainers’ own fix says so in a code comment: completing the invitation “proves control of the emailed tempToken; an SSO login only proves the identity provider’s email assertion, which is not equivalent proof”. The fix in commit 754f3d4 (31 July 2026) simply rejects SSO logins for users who are still INVITED. A follow-up commit on 7 August 2026 also binds each account to the SSO provider and subject ID it first logged in with, so a different identity that happens to report the same email is refused later.

Which Flowise SSO providers widen the exposure?

Flowise Enterprise supports four SSO providers: Microsoft Entra ID (Azure), Google, Auth0 and GitHub. It has no generic OpenID Connect or SAML option, so you cannot point it at Keycloak or another IdP directly. How each provider obtains the email address decides who could exploit a pending invitation.

The table is our reading of the provider files at the [email protected] tag, not something the advisory states. The combination to worry about most is a pending invitation plus a provider that will assert an address nobody verified. The clearest case is Auth0: Flowise does not look at the email_verified flag, so a tenant that allows open sign-ups on a database connection, and has nothing that rejects unverified logins, lets anyone register as [email protected] and complete the takeover. GitHub’s fallback to an unverified address is a narrower version of the same gap.

What should Flowise operators do now?

VulnCheck’s record states that “at the time of the advisory no patched version was available”, and the Flowise repository’s last commit, dated 13 August 2026, added a notice at the top of the README saying the project has been archived. There is no release to upgrade to, so the options are to apply the fix yourself or to remove the precondition.

1. Remove pending invitations while SSO is on. An organisation with no pending invitees has nothing to take over. On the Flowise Users page, remove invited users who have not accepted yet, and re-invite them once you have applied the other steps.
2. Shorten the invitation window. Set INVITE_TOKEN_EXPIRY_IN_HOURS to the smallest value your onboarding process can live with.
3. Tighten each SSO provider. Disable public sign-ups on Auth0 database connections, or add an Auth0 Action that rejects logins whose email is not verified. Prefer Google or a tenant-pinned Entra ID configuration over GitHub for sign-in.
4. Build from the fixed source if you must keep running Flowise. Commits 754f3d4 and 4b805e0 on the archived main branch contain the fix and the identity binding. They are not in any tagged release, so you would be building and maintaining your own image.
5. Audit recent activations. Look for users who went from INVITED to ACTIVE through an SSO login rather than through the invitation link, and for members whose SSO email does not match a person you actually invited.

Longer term, an archived platform will not receive fixes for the next issue either, so treat this as the moment to decide whether Flowise stays in production.

What IdP checks prevent this class of bug in your own apps?

The same mistake is easy to make in any product that sends email invitations and also offers SSO, and AI platforms are shipping those features quickly. If your app uses Keycloak as its identity provider, four checks close most of the gap.

• Trust only verified email. Keycloak includes an email_verified claim in its tokens when the email scope is requested. Your app should refuse to match a login to an existing account or invitation unless that claim is true. In the realm, turning on Verify email under login settings makes Keycloak confirm addresses before users can complete a login.
• Leave Trust Email off for brokered providers you do not control. Each identity provider in Keycloak has a Trust Email setting. When it is off, which is the default, Keycloak does not take the external provider’s word that an address is verified. The Keycloak Server Administration Guide explains that when it is on, users from that provider skip email verification. Our post on attribute mapping during OIDC identity brokering covers how brokered claims reach your app.
• Key accounts on sub, not on email. An email address can be reassigned, added unverified, or shared between providers. The subject identifier is stable per issuer. The Flowise follow-up fix does exactly this by binding each account to its provider and subject ID.
• Keep invitation acceptance as its own step. Keycloak’s Organizations feature sends an invitation as an email link, and a new user must register with the same address the invitation was sent to. Invitations are tracked as Pending or Expired, and since Keycloak 26.5 administrators can view, resend and delete them in the Invitations tab. Possession of the link is what joins the organisation, not a matching email on a later login. See our guide to multitenancy with Keycloak Organizations for the setup.

First broker login has its own version of this problem, where a brokered identity is linked to an existing account because the emails match. We covered that in our post on hardening Keycloak first-broker login for CVE-2026-82968, and the Keycloak security hardening checklist lists the realm settings to review alongside it.

Does this change how you should run identity for AI platforms?

AI builders like Flowise concentrate access: a single workspace can hold API keys for model providers, database connections and internal tools. That makes the join step of an organisation as sensitive as the login itself. The sensible pattern is the same one mature SaaS products use, where a dedicated identity layer owns sign-in, verification and invitations, and the application trusts only the claims that layer has checked. Our post on authenticating AI agents with Keycloak covers the agent side of the same problem, and the guide to securing MCP servers with Keycloak covers the tool side.

Frequently asked questions

Which Flowise versions are affected by CVE-2026-100606?

All Flowise versions up to and including 3.1.4, when running in Enterprise or platform mode with SSO enabled. The CVE record lists no fixed version. A fix exists in commit 754f3d4 on the archived main branch, dated 31 July 2026, but it was never shipped in a tagged release.

Does the attacker need the invitation email?

No, and that is the core of the bug: the attacker only needs to log in at a configured SSO provider with an email claim that matches a pending invitee. Flowise then completes the invitation using the token it already stores, so the emailed link is never used.

Is Keycloak affected by CVE-2026-100606?

No. The vulnerability is in Flowise’s own code, and Flowise’s Enterprise SSO does not support Keycloak or generic OpenID Connect providers. Keycloak is relevant as an example of the identity provider checks, such as verified email and stable subject identifiers, that limit this class of bug in apps you build yourself.

How long does an attacker have to exploit a pending invitation?

As long as the invitation is valid. The CVE record gives 24 hours as the default, and Flowise reads the value from the INVITE_TOKEN_EXPIRY_IN_HOURS environment variable. Deleting pending invitations removes the window entirely while SSO is enabled.

Will Flowise release a patch?

It looks unlikely. The repository was archived in August 2026, its last commit points readers to a “Future of Flowise” discussion, and VulnCheck’s advisory from 26 September 2026 says no patched version was available. Operators who keep Flowise running need to build from the fixed source or rely on the mitigations above.

Sources

• CVE Program, CVE-2026-100606, “Flowise through 3.1.4 … contains an authentication bypass in the SSO login path”, CNA record from VulnCheck, published 26 September 2026, retrieved 2026-09-28, https://www.cve.org/CVERecord?id=CVE-2026-100606 (record JSON: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/100xxx/CVE-2026-100606.json)
• VulnCheck, “Flowise through 3.1.4 Authentication Bypass via SSO Email Match” (linked from the CVE record; not reachable from our research environment), https://www.vulncheck.com/advisories/flowise-through-3.1.4-authentication-bypass-via-sso-email-match
• FlowiseAI, GitHub security advisory GHSA-vf3j-89vf-r697 (linked from the CVE record; not reachable from our research environment), https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-vf3j-89vf-r697
• FlowiseAI, SSOBase.ts and account.service.ts at tag [email protected], retrieved 2026-09-28, https://github.com/FlowiseAI/Flowise/blob/flowise%403.1.4/packages/server/src/enterprise/sso/SSOBase.ts
• FlowiseAI, commit 754f3d4 “fix: flowise-708” (31 July 2026) and commit 4b805e0 “fix: flowise-707” (7 August 2026), retrieved 2026-09-28, https://github.com/FlowiseAI/Flowise/commit/754f3d4747337ec27458a7848e0aa372581d7641
• Jared Hanson, passport-openidconnect, lib/profile.js (maps preferred_username to profile.username), retrieved 2026-09-28, https://github.com/jaredhanson/passport-openidconnect/blob/master/lib/profile.js
• FlowiseAI, SSO provider implementations (GithubSSO.ts, Auth0SSO.ts, AzureSSO.ts, GoogleSSO.ts) at tag [email protected], retrieved 2026-09-28, https://github.com/FlowiseAI/Flowise/tree/flowise%403.1.4/packages/server/src/enterprise/sso
• Keycloak, Server Administration Guide, identity broker configuration (“Trust Email”), keycloak/keycloak at tag 26.7.4, retrieved 2026-09-28, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/server_admin/topics/identity-broker/configuration.adoc
• Keycloak, Server Administration Guide, managing organization members and invitations, keycloak/keycloak at tag 26.7.4, retrieved 2026-09-28, https://github.com/keycloak/keycloak/blob/26.7.4/docs/documentation/server_admin/topics/organizations/managing-members.adoc
• Keycloak, release notes for 26.5.0, “Organization invitation management”, retrieved 2026-09-28, https://github.com/keycloak/keycloak/blob/main/docs/documentation/release_notes/topics/26_5_0.adoc