CVE-2026-53958: 4gaBoards Auth Bypass Vulnerability

CVE-2026-53958 Overview

CVE-2026-53958 is an authentication vulnerability in 4gaBoards, a realtime project management board system. Versions prior to 3.3.9 allow an authenticated user to modify backend-managed SSO identity attributes through the PATCH /api/users/:id endpoint. The whitelist in server/api/controllers/users/update.js mass assigns provider identifiers such as ssoGoogleId, ssoGithubId, ssoMicrosoftId, and ssoOidcId directly from user input. An attacker can plant a victim's provider identifier on an attacker-controlled account, hijacking the victim's first SSO login. The issue is tracked under [CWE-287] and fixed in version 3.3.9.

Critical Impact
Attackers can pre-claim a victim's SSO identity, causing the victim to log into an attacker-controlled account and exposing all subsequently created projects and boards.

Affected Products

4gaBoards versions prior to 3.3.9
Deployments using Google, GitHub, Microsoft, or generic OIDC SSO providers
Self-hosted 4gaBoards instances with local account registration enabled

Discovery Timeline

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

Technical Details for CVE-2026-53958

Vulnerability Analysis

The vulnerability stems from an overly permissive attribute whitelist in the user update controller. The PATCH /api/users/:id endpoint accepts SSO-linked fields including ssoGoogleId, ssoGoogleEmail, ssoGithubId, ssoGithubUsername, ssoGithubEmail, ssoMicrosoftId, ssoMicrosoftEmail, ssoOidcId, and ssoOidcEmail as user-controlled input. These attributes should be assigned exclusively by the backend during identity provider callbacks. When an authenticated attacker writes a victim's provider ID onto their own account, the SSO lookup helpers such as server/api/helpers/users/get-create-one-for-github-sso.js match on the provider identifier first. This match occurs before the email-linkage flow runs, binding the victim's first SSO login to the attacker's account.

Root Cause

The root cause is a mass assignment flaw [CWE-287]. The controller schema in server/api/controllers/users/update.js did not distinguish between user-editable profile attributes and backend-managed identity attributes. Any authenticated user could submit SSO fields in a standard profile update request.

Attack Vector

Exploitation requires an authenticated attacker account and a target victim who will subsequently authenticate via SSO. The attacker sends a PATCH request to /api/users/:id populating the target provider ID field with the victim's identifier from Google, GitHub, Microsoft, or OIDC. When the victim performs their first SSO login, the default lookup returns the attacker's account. The victim's session is bound to the attacker-controlled account, and any projects, boards, or data the victim creates remain accessible to the attacker through the original local credentials.

javascript

       isNotEmptyString: true,
       allowNull: true,
     },
-    ssoGoogleId: {
-      type: 'string',
-      isNotEmptyString: true,
-      allowNull: true,
-    },
-    ssoGoogleEmail: {
-      type: 'string',
-      isEmail: true,
-      allowNull: true,
-    },
-    ssoGithubId: {
-      type: 'string',
-      isNotEmptyString: true,
-      allowNull: true,
-    },
-    ssoGithubUsername: {
-      type: 'string',
-      isNotEmptyString: true,
-      allowNull: true,
-    },
-    ssoGithubEmail: {
-      type: 'string',
-      isEmail: true,
-      allowNull: true,
-    },
-    ssoMicrosoftId: {
-      type: 'string',

Source: GitHub Commit 7a79f4c. The patch removes the SSO fields from the user-editable whitelist so they can no longer be mass assigned via the update endpoint.

Detection Methods for CVE-2026-53958

Indicators of Compromise

PATCH /api/users/:id requests containing ssoGoogleId, ssoGithubId, ssoMicrosoftId, or ssoOidcId fields in the JSON body from non-privileged users
Database records showing SSO provider IDs assigned to accounts that never completed an SSO login flow
Multiple local user accounts sharing or referencing the same provider identifier before a first-time SSO authentication
SSO login events where the resolved account differs from the expected email owner

Detection Strategies

Audit users table entries for SSO ID assignments not originating from provider callback handlers
Instrument server/api/controllers/users/update.js with request logging to capture attempts to write SSO attributes
Correlate first-time SSO authentication events with prior profile update activity on the resolved account
Compare SSO email claims returned by providers against the stored email field on matched accounts

Monitoring Recommendations

Log all HTTP PATCH requests to /api/users/:id with full request body captured for review
Alert on any user profile update that includes provider-linked identity fields
Track ownership changes for boards and projects when the owning account was recently modified
Review SSO helper logs from get-create-one-for-*-sso.js for lookups that resolve to unexpected accounts

How to Mitigate CVE-2026-53958

Immediate Actions Required

Upgrade all 4gaBoards instances to version 3.3.9 or later without delay
Audit existing user records for any SSO identifier that was not populated by a legitimate provider callback
Reset or unbind suspicious SSO linkages before allowing affected users to re-authenticate
Force re-verification of ownership on projects and boards created after the vulnerability window

Patch Information

The fix is included in 4gaBoards v3.3.9. The patch commit is available at GitHub Commit 7a79f4c. Full advisory details are published in GHSA-j2fw-r2gj-hfr3.

Workarounds

Disable SSO providers on the instance until the upgrade to 3.3.9 is complete
Restrict PATCH /api/users/:id at a reverse proxy to strip SSO-related JSON keys from request bodies
Restrict new user registration to trusted administrators to reduce attacker account creation
Enforce email verification before allowing any SSO-first login to bind to an existing local account

bash

# Upgrade example using Docker Compose
docker compose pull 4gaboards
docker compose up -d

# Verify installed version
docker exec 4gaboards node -e "console.log(require('./package.json').version)"
# Expected output: 3.3.9