CVE-2026-53958: 4gaBoards: SSO Pre-Account Takeover / Hijacking via Mass Assignment
4gaBoards is a boards system for realtime project management. Prior to 3.3.9, 4gaBoards allows an authenticated user to modify ssoGoogleId, ssoGoogleEmail, ssoGithubId, ssoGithubUsername, ssoGithubEmail, ssoMicrosoftId, ssoMicrosoftEmail, ssoOidcId, and ssoOidcEmail through PATCH /api/users/:id. The whitelist in server/api/controllers/users/update.js mass assigns these backend-managed identity attributes from user input. An attacker can place a victim's provider identifier on an attacker-controlled account, causing the default lookup in helpers such as server/api/helpers/users/get-create-one-for-github-sso.js to match the victim's first SSO login to the attacker's account before the email-linkage flow runs. The victim is logged into the attacker-controlled account, and projects, boards, or data the victim creates remain accessible through the attacker's original local credentials. This issue is fixed in version 3.3.9.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
4gaBoardsto a version that resolves this vulnerability.Fixed in 3.3.9
Event History
Frequently Asked Questions
Which versions need remediation?
Deploy version 3.3.9 or later. Versions prior to 3.3.9 allow authenticated users to set backend-managed SSO identity attributes through PATCH /api/users/:id.
What does an attacker need to exploit this issue?
Any authenticated user can attempt exploitation over the network with low complexity, but the victim must subsequently sign in through an affected SSO provider for the account mismatch to occur. The attacker needs to supply the victim's provider identifier to their own account.
Which SSO integrations are affected?
The affected endpoint permits changes to Google, GitHub, Microsoft, and OIDC identity IDs and associated email fields. A victim's first SSO login can then be matched to the attacker's account before the email-linkage flow runs.
How can I look for possible exploitation?
Review PATCH requests to /api/users/:id and user records for unexpected values in ssoGoogleId, ssoGithubId, ssoMicrosoftId, ssoOidcId, and their related SSO email or username fields. Investigate accounts whose SSO identifiers correspond to a different user's expected identity, especially where the account has local credentials controlled by another user.