Better Auth released 1.7.16 and 1.8.0-beta.5 to address issues described in 12 security advisories. Its release notice tells developers to update the core library and every installed @better-auth/* package together. Two plugin advisories require a second step: rotating secrets that an upgrade alone cannot invalidate.

Evidence status: vulnerabilities disclosed by the maintainers. The release notice and advisories reviewed here do not report exploitation in the wild. Their account-takeover descriptions establish the reported impact, not a measured number of compromised applications.

Expo exposure needs the server plugin

The critical Expo advisory affects servers registering expo(). The affected @better-auth/expo ranges are 1.4.0-beta.6 through versions before 1.7.16, and 1.8.0-beta.0 through versions before 1.8.0-beta.5.

A public endpoint signed caller-supplied values using the application’s secret. Other authentication features trusted signatures made with that same secret. According to the advisory, an unauthenticated attacker knowing a user’s email address could sign in as that user and change their email. With the session cookie cache enabled, knowing a user ID enabled another impersonation path.

Upgrade both @better-auth/expo and better-auth to the fixed version of your release line. Rotate the application secret if the endpoint was reachable. Previously issued signatures remain valid until the secret changes. If Expo social sign-in is unused, removing the server plugin is the maintainer’s alternative.

The advisory also describes an open redirect and overly broad wildcard origin matching. Wildcard entries in trustedOrigins are an additional prerequisite for the wildcard issue, not for the signing flaw.

Electron can expose more than the auth secret

The Electron advisory affects servers registering electron() from 1.5.0-beta.12 through versions before 1.7.16. The 1.8.0-beta.0 through pre-beta.5 range is also affected.

A sign-in response could return internal server context containing the auth secret and configured social providers’ client secrets. The advisory says any user able to sign in could read those secrets. That creates a wider impersonation risk than exposure of that user’s own session.

Upgrade @better-auth/electron and better-auth together. If the plugin has been running, the maintainers say to treat the auth secret and every social-provider client secret as disclosed and rotate them. Removing the plugin disables desktop sign-in while an upgrade is arranged.

A separate two-factor bypass requires password sign-in, twoFactor(), and electron() appearing before it in the plugin array. Reordering plugins blocks that confirmed bypass on recent releases, but leaves the secret-disclosure problem unresolved.

Check the session and passkey configuration too

The release includes fixes beyond those two plugins:

  • Session revocation: the session advisory covers secondary storage and certain cookie-cache workflows. An attacker already holding a valid session could retain access after revocation. The fix checks stored sessions before sensitive actions and adds a bulk-revocation cutoff. Ordinary cookie-cache validity until maxAge remains documented behavior; disable the cache when immediate revocation is required.
  • Passkeys: the passkey advisory fixes origin and required user-verification checks. Follow its configuration instructions, including an explicit origin when a configured relying-party ID is covered by wildcard allowed hosts. It does not describe unauthenticated registration into someone else’s account.

Inventory enabled server plugins and configuration, rather than assuming every Better Auth installation has every exposure. Check the deployed package versions after rebuilding. Coordinate secret rotation across application instances and social-provider settings, then verify sign-in and revocation through the application’s normal testing process.

The release says Vercel applied web application firewall protections against reasonably identifiable issues. Better Auth still recommends upgrading. Those protections do not rotate an exposed secret or invalidate an already issued signature.

Caveat: these are the supplier’s own disclosures; affected conditions differ by plugin, and the advisory set provides no independently verified victim count.