Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.6",
  "pubDate": "2026-08-18T22:16:54.717Z",
  "pubdate": "2026-08-18T22:16:54.717Z",
  "executiveSummary": "An improper control of generation of code or mass assignment vulnerability exists in 4gaBoards prior to version 3.3.9.\nThe vulnerability allows an authenticated user to modify backend-managed Single Sign-On (SSO) identity attributes, specifically ssoGoogleId, ssoGoogleEmail, ssoGithubId, ssoGithubUsername, ssoGithubEmail, ssoMicrosoftId, ssoMicrosoftEmail, ssoOidcId, and ssoOidcEmail, by sending arbitrary input through the PATCH /api/users/:id endpoint.\nAn attacker can exploit this flaw to hijack a victim's external identity provider association, leading to account takeover upon the victim's subsequent SSO login.\nAffected systems include instances of 4gaBoards running versions prior to 3.3.9.\nThe risk implications are severe, enabling unauthorized access to victim sessions, data exposure, and persistent access to resources created by the victim via the attacker-controlled account.\nExploitation requires an authenticated attacker capable of interacting with the API and leveraging standard SSO login flows.",
  "technicalDetails": "The root cause of the vulnerability resides in the request handling logic implemented within server/api/controllers/users/update.js.\nThe input whitelist fails to properly restrict backend-managed identity attributes, resulting in insecure mass assignment.\nBecause the application accepts user-supplied values for fields such as ssoGoogleId, ssoGoogleEmail, ssoGithubId, ssoGithubUsername, ssoGithubEmail, ssoMicrosoftId, ssoMicrosoftEmail, ssoOidcId, and ssoOidcEmail during a PATCH /api/users/:id request, an authenticated user can overwrite or set these fields on their own account.\nThe attack flow proceeds as follows: First, the attacker authenticates to the application using local credentials. Second, the attacker sends a crafted PATCH request to /api/users/:id containing the victim's provider identifier (e.g., ssoGithubId or ssoGoogleId). Third, the application updates the attacker's account record with the victim's SSO identifier. Fourth, when the victim subsequently attempts to log in using the external SSO provider, helper functions such as server/api/helpers/users/get-create-one-for-github-sso.js perform a default database lookup based on the provider identifier before executing the email-linkage flow. Because the attacker's account now holds the victim's provider ID, the lookup matches the attacker's account instead of creating or mapping the victim's legitimate account.\nConsequently, the victim is logged directly into the attacker-controlled account.\nAny projects, boards, or data subsequently created by the victim within this session remain accessible through the attacker's original local credentials, allowing the attacker to persistently monitor and access sensitive data.\nThe vulnerability affects versions prior to 3.3.9, requires network access to the API, and mandates that the attacker holds an authenticated user session to issue the initial PATCH request."
}