CVE-2026-92161: Unauthenticated Account Takeover in FriendsOfFlarum OAuth Extension

The FriendsOfFlarum OAuth (fof/oauth) extension enables third-party identity provider authentication for Flarum forums. Under typical integration settings, the extension manages user login and registration flows via standard OAuth 2.0 protocols. When a user authenticates via an external provider such as Discord, GitLab, Google, or LinkedIn, the extension resolves the user's registered email address and returns it to the Flarum core application.

The core vulnerability, tracked as CVE-2026-92161, represents an identity provider trust violation under CWE-345. Prior to the patched versions, the extension's Discord integration and several other provider classes blindly trusted the returned email address without validating whether the identity provider had actually verified the user's ownership of that address. Consequently, an attacker can exploit this lack of verification to perform unauthorized account takeover of any local account on a target forum that matches the victim's email address.

This trust boundary breakdown bypasses standard registration verification procedures, converting what should be a suggested email address registration flow into an active session authorization. The flaw operates at the application logic layer and does not require complex cryptographic attacks or network-level interceptions.

The root cause lies in the architectural trust assumptions made when interacting with upstream Identity Providers (IdPs). Within Flarum Core, two methods exist for passing resolved emails from an authentication extension: provideTrustedEmail($email) and suggestEmail($email). Calling provideTrustedEmail($email) asserts that the identity provider has authenticated the user and validated the email address, prompting Flarum Core to auto-link the incoming session to any matching local account.

Conversely, calling suggestEmail($email) only auto-populates the registration form and requires the user to perform standard verification steps before the account is active or linked. Prior to the implementation of the patch, fof/oauth invoked provideTrustedEmail($email) unconditionally for multiple providers, including Discord, GitLab, Google, and LinkedIn.

In the case of Discord, the service permits users to register accounts with arbitrary email addresses and bypass email verification completely if they verify a mobile phone number instead. In such instances, Discord's API response for /users/@me returns the unverified email address alongside a boolean parameter 'verified' set to false. Because the vulnerable versions of fof/oauth failed to inspect this 'verified' flag, they passed the unverified email to Flarum Core via provideTrustedEmail($email), leading to unauthorized session association.

The vulnerability is resolved by implementing conditional validation based on the verification attributes returned in the identity provider payload. Below is a comparative analysis of the changes introduced in the patch for the primary affected providers.

In src/Providers/Discord.php, the previous implementation immediately trusted any retrieved email address. The patched code extracts the payload and verifies the value of the 'verified' key.

// Before Patch: Unconditional trust
$registration
    ->provideTrustedEmail($email)
    ->suggestUsername($user->getUsername() ?: '')
    ->setPayload($user->toArray());
 
// After Patch: Verification check
$payload = $user->toArray();
if ($payload['verified'] ?? false) {
    $registration->provideTrustedEmail($email);
} else {
    $registration->suggestEmail($email);
}
$registration
    ->suggestUsername($user->getUsername() ?: '')
    ->setPayload($payload);

Similar modifications were implemented across other providers. For GitLab (src/Providers/GitLab.php), the code now checks for the presence of the 'confirmed_at' field in the payload. If the field is not empty, the email is marked as trusted; otherwise, the email is treated as suggested. For Google (src/Providers/Google.php), the isEmailTrustworthy() helper method on the user resource owner object is evaluated. For LinkedIn (src/Providers/LinkedIn.php), the 'email_verified' attribute is verified prior to calling provideTrustedEmail().

To execute an exploit against an affected Flarum instance, an attacker must first determine the email address associated with the target victim's account. This reconnaissance step may utilize publicly available information on the forum or forum metadata. Additionally, the target forum must have the fof/oauth extension enabled with Discord or another affected provider configured as an active authentication method.

The attacker then registers a new Discord account using the victim's exact email address. When prompted for verification, the attacker bypasses email validation by linking a mobile phone number to the Discord account. This satisfies Discord's verification requirements for active accounts while leaving the registered email address in an unverified status.

Finally, the attacker visits the target Flarum forum and initiates the "Login with Discord" flow. When redirected to Discord, the attacker authorizes the application. Discord issues an OAuth token and transmits the payload containing the unverified email and verified: false to the Flarum site. The vulnerable extension processes the payload, fails to validate the verified flag, and passes the email to Flarum Core as a trusted address, completing the passwordless login and account takeover.

Successful exploitation of CVE-2026-92161 results in complete, unauthenticated account takeover. An attacker can compromise administrative profiles, gaining full access to sensitive user data, system configuration panels, and restricted forum sections. Because the exploit occurs at the authentication layer, it bypasses any local password requirements, multi-factor authentication (MFA) mechanisms configured on the Flarum instance, and rate-limiting protections.

The vulnerability receives a CVSS v3.1 base score of 9.8, reflecting its critical severity. The attack complexity is low, requiring no specialized privileges or user interaction from the victim. The impact on confidentiality, integrity, and availability is rated high, as the attacker gains full control over the compromised account and can modify system state or lock legitimate users out.

No active exploitation in the wild or weaponized proof-of-concept scripts have been reported. However, the simplicity of the exploitation steps and the widespread use of Discord integration on community forums make rapid patch adoption essential.

Remediation of CVE-2026-92161 requires updating the fof/oauth Composer package to the designated secure versions. For environments running on Flarum 1.x, administrators must upgrade the package to version 1.7.4. For environments utilizing the Flarum 2.x beta branch, the package must be upgraded to version 2.0.0-beta.4.

If immediate package updates are not feasible due to deployment freezes or compatibility testing constraints, administrators must disable the affected OAuth providers (Discord, GitLab, Google, and LinkedIn) in the extension configuration panel. This action removes the vulnerable authentication pathways and forces users to authenticate via secure, verified mechanisms.

System administrators should also audit login logs for occurrences of new OAuth linkages that map to high-privilege administrative accounts. Security teams must ensure that any custom OAuth providers developed internally follow the same validation patterns implemented in the patched files, verifying the email authenticity before delegating trust.