Better Auth EUVD-2026-101745

The target application must have Better Auth configured with BOTH an OAuth/social sign-in provider AND the Magic Link plugin/flow enabled, because the attack cross-uses an OAuth state value against Magic Link verification; applications using only one of these mechanisms are not exploitable. The attacker must also know (or supply) the victim's email address to initiate the OAuth flow. Affected versions are 1.4.0-beta.18 up to but not including 1.7.7. Limiting factors: no special conditions beyond the dual-feature requirement - exploitation is remote and unauthenticated (PR:N, UI:N) against any default configuration that enables both flows, so the primary constraint is deployment configuration rather than authentication or user interaction.

This is a genuine high-priority issue, not a CVSS-inflated paper risk. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H) describes a remote, network-reachable, low-complexity attack needing no privileges and no user interaction, and the described mechanism - reusing an OAuth state value as a Magic Link token to sign in as an arbitrary victim - is consistent with that vector and with the CWE-287 (Improper Authentication) classification. The high confidentiality and integrity impact (full account takeover plus creation of falsely email-verified accounts) is well-supported by the description. Tempering the raw 9.3: no EPSS score is provided, there is no CISA KEV listing, and no public POC is indicated, so there is no evidence of active or widespread exploitation yet. Exploitation is also gated on a specific deployment condition (the target app must enable both OAuth and Magic Link flows), which narrows the real-world exposed population below what AV:N/PR:N alone implies. Net: treat as urgent patch-now for any Better Auth deployment that uses both OAuth and Magic Link, but the absence of EPSS/KEV/POC signals means current exploitation is unproven rather than confirmed.

An attacker initiates an OAuth sign-in flow supplying the victim's email address, captures the OAuth state value returned by Better Auth, and submits that value to the Magic Link verification endpoint. Because the state is accepted as a valid Magic Link token, the attacker is granted an authenticated session as the victim or creates a falsely email-verified account under the victim's identity. No public exploit code is identified at time of analysis, but the attack is low-complexity and requires no authentication or user interaction.