Unauthenticated Account Takeover in FriendsOfFlarum OAuth via Discord's Unverified Email Trust (CVE-2026-92161)

What happened

A GitHub Security Advisory (GHSA-g7vj-c29h-3h5m, CVE-2026-92161, CVSS 9.8) discloses an unauthenticated account takeover vulnerability in the fof/oauth extension for Flarum forums when the Discord OAuth provider is enabled. According to the advisory, Discord permits an account to register an unverified email address as long as a phone number has been verified, and Discord's OAuth response can return that email with "verified": false". Affected versions of fof/oauth did not check this flag before calling Flarum's provideTrustedEmail(), so Flarum core treated the attacker-supplied, unverified email as trusted and linked the attacker's Discord identity to any existing forum account with a matching email — authenticating the attacker as that user, including administrators. A public proof-of-concept exists (exploit_status: poc-public).

Why it matters for defenders

This is a no-interaction, no-password-required account takeover: an attacker only needs to know a victim's email address, register a Discord account using that email (unverified) plus a verified phone number, and sign in via Discord OAuth on the target forum. Any Flarum instance running fof/oauth with Discord sign-in enabled is potentially exposed, and administrator accounts are explicitly called out as takeover targets — a compromise there can cascade into full forum control (plugin management, user data, further pivoting).

What defenders should watch for / do now

• Identify any Flarum deployments running fof/oauth and check whether the Discord provider is enabled.
• Update to the patched releases named in the advisory: 1.7.4 or 2.0.0-beta.4.
• If patching isn't immediately possible, disable the Discord OAuth provider in extension settings as an interim workaround (per the advisory).
• Review authentication and admin-panel logs for accounts that were newly linked to a Discord identity, or admin/privileged sessions originating from an OAuth login shortly after account creation, as a hunting angle — this is a general pattern to look for, not a validated detection.
• Consider auditing other bundled OAuth providers for similar unverified-email trust issues, though the advisory notes other providers were not confirmed exploitable via this same method.

Developing intel

This item is based solely on the GHSA disclosure published today and reflects only what the advisory states; no independent detection query or additional confirmation is included here. For full technical detail, workarounds, and credit, see the original advisory: GHSA-g7vj-c29h-3h5m.