4gaBoards CVE-2026-50191

Exploitation requires all three of the following configuration flags to be simultaneously enabled on the target instance: registrationEnabled=true, localRegistrationEnabled=true, and ssoRegistrationEnabled=true. At least one external SSO provider must be configured (Google OAuth, GitHub OAuth, Microsoft OAuth, or an OIDC provider). The attack is further gated on the victim having never previously logged in via SSO on that instance - once a victim has already linked their SSO identity to a legitimately created and verified account, the vulnerable code path would find an already-verified account and the attacker's pre-registration would be ineffective. Exploitation requires no authentication on the attacker's side (PR:N). The limiting factor is UI:R: the victim must complete their first SSO login after the attacker's stub account is in place. Non-default condition: all three registration flags must be concurrently enabled alongside SSO provider configuration, which is not a guaranteed default deployment posture.

The CVSS 8.8 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) accurately captures the threat profile: the attack is network-reachable, requires no privileges, and results in full account compromise. The sole limiting factor is UI:R - the victim must perform their first SSO login after the attacker has pre-registered the stub account. This is not a true race condition in the classical sense; the attacker simply needs to register before the victim ever uses SSO, giving an indefinite window. EPSS data was not provided, but given the niche deployment footprint of 4gaBoards and the absence of KEV listing or known POC, opportunistic mass exploitation is unlikely. Targeted exploitation against specific individuals or organizations using 4gaBoards with SSO is the realistic threat. The attack is highly deterministic - no brute force, no timing race, no special tooling needed - which elevates practical risk above what EPSS alone would suggest for a low-prevalence product. No conflicting signals between CVSS and description were identified.

An attacker identifies a 4gaBoards instance with open registration and SSO enabled, and knows or guesses a target user's email address (e.g., from LinkedIn or a public project). The attacker calls POST /api/register with the victim's email and a chosen password, creating an unverified local account; the attacker then calls POST /api/access-tokens to confirm session access works with isVerified=false. When the victim next attempts to log in via their corporate Google SSO, the server locates the attacker's stub account by email match, links the Google identity to it, and the attacker retains local-password access - now with full visibility into the victim's board data, project permissions, and organizational context.