CVE-2026-50191 in 4gaBoards
Summary
by MITRE • 08/19/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in 4gaBoards prior to version 3.3.8 represents a critical pre-account takeover flaw rooted in flawed identity resolution logic during Single Sign-On integration. The application, designed for real-time project management, allows users to register via local credentials or various external Identity Providers such as Google, GitHub, Microsoft, and OIDC compliant services. Under specific configuration states where registration is enabled through any of these channels, the system fails to properly validate ownership when merging identities. This architectural weakness permits an attacker to hijack existing user accounts by exploiting the sequence in which account creation and SSO linking occur, effectively bypassing standard verification protocols that are intended to prevent unauthorized access.
The technical mechanism of this exploitation begins with the POST /api/register endpoint, which allows for the creation of a local account using any email address without requiring immediate verification of ownership via email confirmation or other out-of-band methods. Once an unverified local account is established under the victim's email, the attacker utilizes the POST /api/access-tokens endpoint to authenticate against this newly created but unverified account. The system erroneously permits authentication even when the isVerified flag is false, establishing a session for the attacker-controlled entity. This step is crucial as it provides the necessary context and credentials required to trigger the subsequent identity linking process without raising security flags regarding the lack of email verification.
The core failure occurs during the victim's first attempt to log in using their configured SSO provider. When the victim authenticates via Google, GitHub, Microsoft, or OIDC, the server-side helper functions located at server/api/helpers/users/get-create-one-for-github-sso.js and similar files for other providers are invoked. These helpers search for an existing account associated with the email address returned by the Identity Provider. Instead of detecting a conflict between the unverified local account and the newly authenticated SSO identity, or requiring re-verification of ownership before linking, the system automatically associates the verified SSO identity with the attacker-controlled local account. This action effectively transfers control of the victim's data to the attacker while leaving the original password-based access intact for the malicious actor.
The operational impact of this vulnerability is severe, resulting in a complete compromise of user privacy and organizational security posture. By successfully linking their unverified account to the victim's verified SSO identity, attackers gain immediate access to all projects, files, messages, and permissions associated with that email address. This constitutes a pre-account takeover scenario where no prior interaction with the victim is required other than knowing their email address. The attacker retains persistent local-password access alongside the SSO-linked privileges, ensuring continued unauthorized entry even if the victim attempts to change passwords or revoke specific tokens. This leads to potential data exfiltration, sabotage of project workflows, and further lateral movement within organizations that rely on 4gaBoards for collaboration.
From a classification perspective, this vulnerability aligns with CWE-287: Improper Authentication, specifically regarding the failure to verify identity before granting access or merging accounts. It also relates closely to CWE-601: URL Redirection to Untrusted Site (Open Redirect) in the context of state manipulation during account linking, though more accurately it fits CWE-359: Exposure of Private Personal Information to an Unauthorized Actor due to improper ownership verification. In terms of MITRE ATT&CK framework tactics, this behavior facilitates Account Manipulation and Initial Access by allowing adversaries to assume legitimate user identities without valid credentials for the primary authentication method. The lack of a challenge-response mechanism or re-verification step when merging accounts is a common anti-pattern in identity management systems that fails to adhere to zero-trust principles where every change to account ownership must be rigorously validated.
Mitigation strategies focus on enforcing strict verification protocols during identity resolution and linking processes. Organizations running versions prior to 3.3.8 should upgrade immediately as the vendor has released a patch addressing this logic flaw. For environments unable to update instantly, administrators can disable local registration or restrict SSO providers if feasible, though upgrading remains the only definitive solution. Future implementations of similar systems must ensure that when an existing account is found during SSO login, the system verifies ownership by requiring re-authentication via email confirmation or a secondary factor before linking new identities. This prevents attackers from leveraging unverified local accounts as footholds to hijack verified external identities. Additionally, implementing unique constraints on email addresses combined with mandatory verification steps prior to any authentication token generation would significantly reduce the attack surface for such pre-account takeover vulnerabilities.