Fix CVE-2026-121802 in Better Auth Expo: upgrade and rotate the secret

Upgrade both better-auth and @better-auth/expo, then rotate the application secret if the affected endpoint was reachable. The fixed release lines are 1.7.16 for stable deployments and 1.8.0-beta.5 for beta deployments. A package upgrade alone does not invalidate signatures produced before the fix. See the vendor advisory.

Check whether your deployment is affected

The issue concerns servers that register the expo() plugin from @better-auth/expo. Installing an Expo client dependency does not, by itself, establish that the server exposes the affected authorization proxy.

The advisory describes unauthenticated account access and email changes when a user's email address is known. Session cookie caching is not required for that impact; it adds another impersonation case. Wildcard trusted-origin handling and an open redirect are also addressed by the release.

The Casco CVE page provides the record overview. The canonical CVE record assigns CVSS 3.1 9.1 and links this advisory. Its original publication was November 4, 2026, at 02:36:13 UTC. The vendor advisory and fixed stable release were published on November 3; those are separate timestamps.

Update the server and verify the deployed packages

1. Inventory each auth deployment. Record its resolved package versions, lockfile, server plugin registration, auth base path, and secret source. Check every replica and deployment region, not only a developer's manifest.
2. Prepare recovery. Back up the auth database and configuration securely. Identify data encrypted with the existing application secret before replacing it. Keep secret values out of tickets, terminal captures, and build logs.
3. Update both packages on the same release line. Use your package manager to select the fixed targets above and update the lockfile. The 1.7.16 release contains several security changes; check the other plugins your application uses as part of release review.
4. Rebuild and deploy all auth instances together. Verify the versions inside the deployed artifact. For a coordinated cutover, drain old instances so requests cannot reach an affected server with the previous secret.
5. Rotate and validate the application secret. If the endpoint was reachable, complete the vendor-required rotation after upgrading. Record the deployment and rotation times without recording the secret itself.

Plan secret rotation and sign-in continuity

The Better Auth security documentation distinguishes encryption-key rotation from upgrades that change pending OAuth or SAML state. Versioned secrets can preserve access to encrypted data, but pending flows may still need to restart. Review that guidance against your configured storage and secret options before the cutover.

The remediation goal is to stop accepting signatures produced with the old application secret. Confirm that outcome for your configuration; retaining an old key for data recovery is not evidence that old signatures are rejected. Coordinate the new configuration across all replicas, restart pending sign-in and account-linking flows, and prepare support for users who must authenticate again.

If Expo SSO fails after upgrading, the vendor says to add the configured identity provider's origin to trustedOrigins. Review the exact provider origin and application scheme instead of broadening the allowlist indiscriminately. The Expo integration guide explains server registration and mobile callback configuration.

Verify with disposable test accounts

Use an isolated application configuration and synthetic identities. Do not use another person's account or probe a production endpoint to reproduce account takeover.

• Complete ordinary Expo social sign-in and account linking, including the configured SSO provider where applicable.
• Confirm the callback returns to the intended application and that unrelated redirect origins are refused.
• Check that unissued or expired state cannot obtain a newly signed state cookie. An HTTP status alone does not prove this: inspect the cookie behavior and resulting authenticated identity.
• Confirm the old secret no longer authorizes synthetic pre-rotation signatures, then verify that newly issued sign-in flows still work.

Record the tested artifact, configuration, expected result, and actual result. Repeat the deployment inventory afterward so a successful test cannot mask an old replica.

If the update cannot be completed immediately

Where Expo social sign-in is unused, the vendor's workaround is to remove the server's expo() plugin. Otherwise, restrict access to the affected functionality while preparing the update. The advisory's temporary request filter covers the signing flaw only; do not treat it as a replacement for the complete release.

If recovery requires an affected build, keep the relevant endpoint disabled or restricted. Do not restore the previous signing secret as a routine rollback step. Investigate suspicious account or email changes through your incident-response process.

Verification evidence and limits

Research and component checks were performed on November 4, 2026 (UTC).

The stable 1.7.16 tag resolves to 93edae16ebae910f57df360d0f43c2dcfa9f8c20. In its authorization-proxy route, signing requires an unexpired server-side state record. The route also checks the authorization provider's origin.

Isolated checks also exercised the published 1.7.15 and 1.7.16 packages through their in-process auth handlers, with an in-memory database and synthetic state. The following table summarizes six distinct checks; two additional old-version requests repeated the opaque-state behavior.

The sanitized evidence records the package identities and outcomes. These checks made no external OAuth request and did not attempt account takeover. They do not establish mobile-app behavior, SSO compatibility, secret-rotation correctness, or the security of a running deployment. The beta release was not executed. Use the deployment checks above for your installation.