Better Auth fixes 12 issues in its November 2026 security release, including a critical Expo plugin flaw that allows account takeover

On November 3, 2026, Better Auth published a security release that fixes the issues in 12 GitHub security advisories. The fixes are in better-auth 1.7.16 and 1.8.0-beta.5. Plugins and adapters released as separate packages, such as @better-auth/expo, @better-auth/electron, @better-auth/passkey, @better-auth/stripe and @better-auth/kysely-adapter, ship with the same version numbers, and Better Auth says to update every Better Auth package together. Each advisory lists the affected versions and the settings that decide whether your app is affected. Better Auth rates one critical, two high, eight medium and one low.

The critical issue: the Expo plugin

GHSA-4wq4-2ppv-q3hg affects any server that registers the expo() plugin from @better-auth/expo 1.4.0-beta.6 until 1.7.16, and from 1.8.0-beta.0 until 1.8.0-beta.5. No other setting is needed. The plugin adds a public endpoint that helps the system browser start a social sign-in. That endpoint signed a value taken from the request with the application secret, and Better Auth uses the same secret for email verification links and, when it is on, the session cookie cache. An attacker without an account who knows a user's email address can sign in as that user and change the account's email address, with no action from the user. With the session cookie cache on, knowing a user's ID is enough to act as that user. The same endpoint could also redirect visitors to any outside HTTPS site.

CVE-2026-121802 covers this issue and scores it CVSS 3.1 9.1 Critical. Its description says the application secret must be rotated after updating. The advisory explains why: signatures made before the fix stay valid until the secret changes. If Expo sign-in through an SSO identity provider stops working after the upgrade, add the provider's origin to trustedOrigins. If you cannot upgrade yet and do not use Expo social sign-in, remove the expo() server plugin. Otherwise, the advisory says to block requests to /expo-authorization-proxy whose authorizationURL carries a state value that is not exactly 32 characters from A-Z, a-z, 0-9, - and _. That blocks the signing problem only.

The two high issues

GHSA-q747-mqgr-4gh7 affects the phone number plugin. Sign-up and other flows could save a phone number on an account before anyone proved they own it. An attacker can put a victim's number on an account the attacker controls. When the victim later signs in with a valid code sent to their own phone, they land in the attacker's account, and what they enter there may reach the attacker. The attacker does not get into the victim's own account. After upgrading to 1.7.16, clear saved phone numbers that were never verified. Those users will need to add their numbers again.

GHSA-9p5w-h4pr-fcrc affects servers that register the electron() plugin from @better-auth/electron 1.5.0-beta.12 until 1.7.16, and from 1.8.0-beta.0 until 1.8.0-beta.5. A normal sign-in could return the server's internal auth context, which includes the auth secret and the client secrets of configured social providers. Any user who can sign in could read them, and with the auth secret could get a session as another user whose email address they know. In some plugin orders, a password sign-in could also skip two-factor. If the plugin has been running, treat the auth secret and every social provider client secret as exposed and rotate them.

The other nine

The medium issues cover email change links that stay valid after an address changes hands, OAuth sign-in treating an unverified provider email as verified, MySQL serial IDs returning another request's record in the Kysely and Drizzle adapters, revoked sessions staying valid with secondary storage or the cookie cache, an email one-time code limit that can be raced, with codes loosely bound to addresses, admin roles holding user:update changing another user's phone number, organization admins inviting an owner with a padded role name, and Stripe billing actions. GHSA-x8j7-xh58-rv6x says a signed-in user of an app that registers the stripe() plugin from @better-auth/stripe 1.2.0-beta.18 until 1.7.16, or from 1.8.0-beta.0 until 1.8.0-beta.5, who knows another customer's Stripe ID could set that ID on their own account, then open that customer's billing portal, see invoices, change payment methods, and cancel or change subscriptions. That needs subscription billing turned on (subscription.enabled: true). The upgrade does not repair IDs already saved, so find Stripe customer IDs held by more than one user and check each against the customer's metadata.userId in Stripe, and check organization records if organization billing is on. The low issue is passkey verification that did not enforce origin or user verification.

On Vercel

Vercel's bulletin says it deployed WAF rules for every project on Vercel that block the request patterns it can identify, including the critical Expo issue. Logic issues, such as session revocation with secondary storage, cannot be blocked by a WAF and are fixed only by upgrading. Vercel says the WAF cannot invalidate signatures forged before the rules went live, so apps using the expo() plugin should still upgrade and rotate their application secret.

An earlier Better Auth flaw has its own item: an OAuth sign-in state accepted as a Magic Link token.