Act nowDisclosed

Advisory · CVE-2026-110862

Better Auth magic link flaw lets unauthenticated users sign in as others

Better Auth from 1.4.0-beta.18 before 1.7.7 reuses OAuth state values as magic link tokens, letting unauthenticated attackers sign in as other users. CVSS 3.1 9.1.

Vendor
Better Auth
Product
Better Auth
Identifier / CWE
CVE-2026-110862
CWE-287
Action timing
Immediate
ELI5

Explain it like I’m five

A login ticket meant for one door is accepted at a different door, so anyone holding it can walk in as someone else.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01OAuth sign-in started

    An unauthenticated attacker starts an OAuth sign-in using a victim email address.

  2. 02State value returned

    The flow returns an OAuth state value for that attempt.

  3. 03State replayed as magic link

    The attacker submits the state value to magic link verification instead.

  4. 04Victim session issued

    The application accepts it and creates a session, or a falsely verified account, for the victim.

What happened

The GitHub advisory for Better Auth describes an authentication bypass in releases from 1.4.0-beta.18 before 1.7.7. OAuth state values can be reused as magic link tokens.

An attacker who starts an OAuth sign-in with a victim email address can submit the returned state to the magic link verification path and gain a session, or create an account treated as email verified for that victim.

What to do

  1. Inventory applications using Better Auth, especially those offering both OAuth and magic link sign-in.
  2. Upgrade Better Auth to 1.7.7 or later using the project advisory guidance.
  3. Review sign-in logs for magic link verifications that follow abandoned or mismatched OAuth attempts.
  4. Invalidate active sessions and re-verify accounts created through magic link flows during the exposure window where abuse cannot be ruled out.
  5. Verify the deployed version after the upgrade.

Management note

Unauthenticated account takeover in a widely used auth library is an act-now item. Patch first, then audit sessions and new accounts, because a clean version number alone does not undo a takeover that already happened.