Better Auth CVE-2026-114607

Exploitation requires a precise configuration combination, all of which must hold: (1) the Magic Link plugin enabled with storeToken set to the default 'plain', OR storeToken 'hashed' together with the global verification.storeIdentifier also set to 'hashed'; (2) at least one built-in social provider or Generic OAuth provider enabled; and (3) account.storeStateStrategy set to 'database' (the default whenever a database or secondary storage is configured). The attacker additionally must know the victim's email address. LIMITING FACTORS that block or reduce exploitation: cookie-backed OAuth state (account.storeStateStrategy='cookie') prevents this path (subject to a separate OAuth Proxy shared-secret caveat); setting storeToken to 'hashed' while leaving global verification.storeIdentifier unset or 'plain' prevents it; disabling either Magic Link or all social/Generic OAuth sign-in prevents it. Note: disableSignUp:true is explicitly NOT sufficient - it only blocks creation of new wrongly-verified accounts and does not stop takeover of existing accounts.

This is a genuine high-priority issue, not an inflated-CVSS artifact. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:H/I:H) describes a network-reachable, unauthenticated, low-complexity authentication bypass that lets an attacker who merely knows a victim's email address obtain a full session for that account - consistent with the CWE-287 (Improper Authentication) classification and the 9.1 score. The vuln.today decision label is 'act_now', reinforcing urgency. However, key quantitative exploitation signals are MISSING: no EPSS probability is provided, there is no CISA KEV listing in the input, and no SSVC decision tree values (automatable, technical impact) are supplied beyond the vendor-style 'act_now' label. No public exploit code is present either - the four references are all remediation artifacts (GHSA advisory, fix PR #11494, fix commit, and the v1.7.7 release), not a working PoC. The practical risk tempering factor is configuration dependence: exploitation only applies to deployments matching a specific combination of Magic Link, OAuth provider, token-storage, and state-strategy settings (detailed below), several of which happen to be defaults, which is why the severity remains high rather than theoretical. Net: treat as a real, actively-fixable priority for affected Better Auth deployments; the high CVSS is justified by impact and preconditions, but the absence of EPSS/KEV data means widespread active exploitation is not confirmed.

An attacker targets a Better Auth app that uses the Magic Link plugin alongside a social or Generic OAuth provider with database-backed OAuth state. The attacker initiates an OAuth sign-in for a victim's known email address, captures the OAuth state value the server returns, then submits that state value to the Magic Link verification endpoint as if it were a Magic Link token - because both resolve to the same stored verification identifier, the server grants a valid session for the victim without the attacker ever controlling the mailbox or completing the OAuth callback. No public exploit code is identified at time of analysis; the only published code is the vendor fix.