CVE-2026-50191: 4gaBoards Auth Bypass Vulnerability

CVE-2026-50191 Overview

CVE-2026-50191 is a pre-account takeover vulnerability in 4gaBoards, an open-source realtime project management board system. Versions prior to 3.3.8 allow an attacker to register an unverified local account using a victim's email address, then hijack that account when the victim later signs in through Google, GitHub, Microsoft, or OpenID Connect (OIDC) single sign-on (SSO). The SSO helpers link the verified identity to the attacker-controlled local account without confirming ownership. This weakness maps to [CWE-287] Improper Authentication.

Critical Impact
An attacker who registers before the victim's first SSO login retains local-password access to the linked account and inherits the victim's projects, data, and permissions.

Affected Products

4gaBoards versions prior to 3.3.8
Instances with registrationEnabled, localRegistrationEnabled, and ssoRegistrationEnabled all enabled
Instances configured with Google, GitHub, Microsoft, or OIDC SSO

Discovery Timeline

2026-08-18 - CVE-2026-50191 published to NVD
2026-08-19 - Last updated in NVD database

Technical Details for CVE-2026-50191

Vulnerability Analysis

The flaw lives in how 4gaBoards reconciles local accounts with federated identities. The POST /api/register endpoint accepts an arbitrary email address and creates a local account with isVerified set to false. The POST /api/access-tokens endpoint then permits that unverified account to authenticate normally. When the legitimate owner of the email address later signs in via SSO for the first time, the server looks up an existing user by email and attaches the SSO identity to whatever record it finds. The attacker's pre-existing local password remains valid on the now-linked account, granting persistent access to the victim's workspace.

Root Cause

The SSO helpers server/api/helpers/users/get-create-one-for-github-sso.js, get-create-one-for-google-sso.js, get-create-one-for-microsoft-sso.js, and get-create-one-for-oidc-sso.js perform email-based user matching without verifying that the local account belongs to the SSO principal. Combined with the ability to authenticate unverified accounts, the trust boundary between local and federated identities collapses.

Attack Vector

The attack requires network access to the registration endpoint and user interaction from the victim, who must complete their first SSO login after the attacker plants the account. No prior privileges are required. The attacker executes the following logical sequence:

Identify a target email tied to an anticipated SSO user.
Call POST /api/register with that email and an attacker-chosen password.
Wait for the victim to sign in through Google, GitHub, Microsoft, or OIDC.
Continue authenticating with POST /api/access-tokens using the original password, now against the fully linked and verified account.

The upstream patch invalidates existing sessions and clears the password when linking an SSO identity to an unverified account:

javascript

         ssoGithubId: inputs.id,
         ssoGithubEmail: email,
       };
+      if (!user.isVerified) {
+        await Session.update({
+          userId: user.id,
+          deletedAt: null,
+        }).set({
+          deletedAt: new Date().toUTCString(),
+        });
+        updatedValues.password = null;
+      }
       if (core.syncSsoDataOnAuth) {
         if (isUsernameAvailable && inputs.username !== user.username) {
           updatedValues.username = inputs.username;

Source: GitHub commit 484c92d. Equivalent changes are applied in the Google, Microsoft, and OIDC helper files.

Detection Methods for CVE-2026-50191

Indicators of Compromise

Local accounts created via POST /api/register that never completed email verification but later gained an ssoGithubId, ssoGoogleId, ssoMicrosoftId, or ssoOidcId value.
Successful POST /api/access-tokens authentications against accounts where isVerified was false at the time of token issuance.
Two authentication paths, local password and SSO, active on the same user account within a short window.

Detection Strategies

Query the users table for records where an SSO identifier was populated after the account was registered locally and before isVerified became true.
Correlate registration events with subsequent SSO link events keyed on email address to surface pre-registration patterns.
Review web server logs for bursts of POST /api/register requests preceding first-time SSO logins for the same email domain.

Monitoring Recommendations

Alert on any authentication using a local password against an account that also has an SSO identity linked.
Track first-time SSO logins that resolve to an existing local user rather than provisioning a new record.
Retain registration, session, and SSO linkage events for forensic reconstruction of account merges.

How to Mitigate CVE-2026-50191

Immediate Actions Required

Upgrade 4gaBoards to version 3.3.8 or later, which invalidates sessions and clears local passwords when linking SSO to unverified accounts.
Audit existing accounts for evidence of the linkage pattern described above and force password resets on affected users.
Revoke active sessions for any account where SSO was linked to a previously unverified local record.

Patch Information

The fix is available in 4gaBoards Release v3.3.8. Technical details are documented in GitHub Security Advisory GHSA-f3p6-chc6-pc77 and the corresponding remediation commit.

Workarounds

Disable localRegistrationEnabled or ssoRegistrationEnabled until the upgrade is applied to prevent unverified accounts from being auto-linked at first SSO login.
Require email verification before allowing authentication via POST /api/access-tokens for any newly created local account.
Restrict SSO login to a preprovisioned user list so the linking helpers cannot match arbitrary attacker-registered emails.

bash

# Upgrade example using Docker Compose
docker compose pull 4gaboards
docker compose up -d 4gaboards
docker exec 4gaboards node --version
# Verify running version matches v3.3.8 or later in the UI