CVE-2026-114607

Better Auth from 1.4.0-beta.18 before 1.7.7 contains an authentication bypass vulnerability that allows unauthenticated attackers to sign in as other users by reusing OAuth state values as Magic Link tokens. Attackers can start an OAuth sign-in with a victim's email and submit the returned state to Magic Link verification, gaining sessions or creating falsely email-verified accounts.

Better Auth library before version 1.6.11 has a vulnerability in the @better-auth/sso plugin. The POST /sso/register and POST /sso/update-provider endpoints accept attacker-controlled URLs (oidcConfig.userInfoEndpoint, tokenEndpoint, jwksEndpoint) when skipDiscovery: true is set, store them without origin validation, and fetch them during OIDC callback, allowing non-blind server-side request forgery (SSRF) and potential account linking when trustEmailVerified: true is configured.

Better Auth before version 1.6.11 has a vulnerability in the legacy oidcProvider and mcp plugins where OAuth token endpoints authenticate only possession of a valid refresh_token and client_id, without verifying the client_secret. This allows an attacker with a valid refresh_token to mint access tokens and rotated refresh tokens via /api/auth/oauth2/token or /api/auth/mcp/token.

In Better Auth versions prior to 1.3.26, an unauthenticated attacker can create or modify API keys for any user by passing that user's id in the request body to the api/auth/api-key/create route. When no session exists but userId is present, authRequired becomes false and server-only field validation is skipped, allowing privileged fields to be set. The same pattern exists in the update endpoint; this is a critical authentication bypass fixed in version 1.3.26.

Better Auth from 1.5.0-beta.12 before 1.7.7 contains an authentication bypass vulnerability in the OAuth Proxy plugin that allows unauthenticated attackers to sign in as other users by forging encrypted profiles. When the proxy shares the global secret and cookie-stored state is used, an attacker can obtain encrypted state for a fake profile with a victim's verified email to take over the account via implicit linking.

Better Auth @better-auth/drizzle-adapter and better-auth from 1.6.17 before 1.7.7, and @better-auth/kysely-adapter from 1.6.17 before 1.7.0, contain a race condition in database-backed rate limiting on PostgreSQL where the limit check is not atomic with the counter update. Remote attackers can send bursts of concurrent requests that pass the check together, exceeding configured limits on password sign-in, two-factor verification, one-time code, password reset, and other rate-limited endpoints.

better-auth from 1.3.8-beta.3 before 1.7.0-rc.3 contains a UI misrepresentation vulnerability in the deviceAuthorization plugin because GET /device omits the requesting client_id and scope. Attackers can start a device request via /device/code, trick signed-in users into approving the code, then redeem it at /device/token for a live session token.

better-auth (npm) before version 1.4.2 allows an external request to configure baseURL when it is not otherwise defined (e.g., BETTER_AUTH_URL is unset). An attacker able to make the very first request to the server after startup can poison the router's base path, causing all routes to return 404 for all users (denial of service). The issue is not reachable when baseURL is explicitly configured or on typical managed hosting platforms.

better-auth passkey before version 1.4.0 has an insecure direct object reference vulnerability in the passkey deletion endpoint. Authenticated users can delete arbitrary passkeys of other users.

Better Auth relies on the rou3 router library, which normalizes URL paths by removing empty segments. In Better Auth versions prior to 1.4.5, an attacker can bypass disabledPaths configuration and path-based rate limits by submitting requests with extra slashes in the URL path. The issue does not apply when the proxy or platform normalizes URLs by collapsing multiple slashes.