CVE-2026-50191: 4gaBoards: Pre-Account Takeover via SSO Email Linkage
4gaBoards is a boards system for realtime project management. Prior to 3.3.8, 4gaBoards is vulnerable to pre-account takeover when registrationEnabled, localRegistrationEnabled, and ssoRegistrationEnabled are enabled and Google, GitHub, Microsoft, or OIDC SSO is configured. The POST /api/register endpoint permits creation of an unverified local account with a victim's email address, and POST /api/access-tokens permits that account to authenticate while isVerified is false. During the victim's first SSO login, server/api/helpers/users/get-create-one-for-github-sso.js, server/api/helpers/users/get-create-one-for-google-sso.js, server/api/helpers/users/get-create-one-for-microsoft-sso.js, and server/api/helpers/users/get-create-one-for-oidc-sso.js find the attacker-controlled account by email and link the verified SSO identity without confirming ownership of the local account. The attacker can retain local-password access to the linked account and obtain the victim's projects, data, and permissions. This issue is fixed in version 3.3.8.
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.8
Event History
Frequently Asked Questions
Which deployments are affected?
Instances prior to 3.3.8 are exposed only when registrationEnabled, localRegistrationEnabled, and ssoRegistrationEnabled are enabled and Google, GitHub, Microsoft, or OIDC SSO is configured.
What does an attacker need to exploit this issue?
An attacker needs no existing account or privileges, but must be able to submit registration requests and create a local account using the intended victim's email address. Exploitation is completed when that victim first signs in through the configured SSO provider.
What can be done if an immediate upgrade is not possible?
Upgrade 4gaBoards to version 3.3.8. If upgrading cannot happen immediately, disabling one or more of local registration, SSO registration, or the affected SSO configuration removes the stated exposure conditions.
How can administrators look for signs of compromise?
Review whether unverified local accounts were created with email addresses belonging to SSO users, particularly where those accounts later became linked to Google, GitHub, Microsoft, or OIDC identities. Such accounts may retain attacker-controlled local-password access after SSO linkage.