Threat Intelligence Database

better-auth (npm) versions before 1.4.2 have a vulnerability where an external request can set the baseURL if it is not predefined (e.g., BETTER_AUTH_URL unset). This allows an attacker making the first request after server startup to poison the router's base path, causing all routes to return 404 errors and resulting in denial of service for all users. The vulnerability is not exploitable if baseURL is explicitly configured or on typical managed hosting platforms.

A vulnerability in better-auth causes stale user sessions to persist after user deletion when using external session caches and the session is not stored in the database. This affects user deletion flows in the admin, anonymous, and SCIM plugins, allowing deleted users' sessions to remain valid until the session TTL expires (default 7 days). The issue is fixed in patched versions of better-auth and @better-auth/scim, which ensure sessions are deleted before user records. Workarounds include enabling session storage in the database or explicitly revoking sessions in code. The impact is limited to session persistence post-deletion, with no known exploits in the wild.

A race condition in @better-auth/oauth-provider versions >=1.6.0 and <1.6.11 allows concurrent redemption of the same OAuth authorization code. This occurs because the token endpoint uses a non-atomic find-then-delete operation to consume single-use authorization codes, enabling multiple token sets to be issued from one code. The issue also affects legacy plugins in better-auth versions >=1.4.8-beta.7 and <1.6.0. The vulnerability violates RFC 6749's single-use code requirement and can lead to multiple valid tokens from a single authorization code.

A vulnerability in @better-auth/oauth-provider versions >=1.6.0 and <1.6.11 allows concurrent refresh token redemption to fork the refresh token family. This occurs because the refresh token rotation process is not atomic, enabling two concurrent requests using the same refresh token to both succeed and mint new tokens. This breaks the intended single-use refresh token rotation and can allow indefinite access token renewal until expiration or revocation. The issue is fixed in version 1.6.11 by implementing an atomic compare-and-swap operation during token rotation and adding a unique constraint on refresh tokens.

The better-auth library versions prior to 1.6.11, when using the legacy oidcProvider or mcp plugins, have insecure cryptographic defaults. These include advertising the 'none' algorithm for ID token signing in the discovery document, which can lead to acceptance of unsigned tokens by relying parties that do not pin algorithms. Additionally, the default acceptance of the PKCE 'plain' code challenge method violates OAuth 2.1 standards and weakens authorization code protection if the authorization URL is exposed. The newer @better-auth/oauth-provider package is not affected. A fix is available in better-auth version 1.6.11 and later.

A stored cross-site scripting (XSS) vulnerability exists in the Better Auth authorization server when using the deprecated oidc-provider or mcp plugins in versions prior to 1.6.13. The vulnerability arises from improper validation of redirect_uri values during OAuth client registration, allowing an attacker to register a javascript: URI. When the consent page navigates to this URI, attacker-controlled JavaScript executes in the authorization server origin, risking session exposure and account takeover. The issue is fixed in better-auth versions 1.6.13 and later.

A vulnerability in better-auth versions prior to 1.6.11 allows an attacker to perform account takeover via OAuth auto-linking to an unverified pre-registered email. The flaw arises because the OAuth callback implicitly links accounts based only on the OAuth provider's email verification claim, ignoring the local user's email verification status. This enables an attacker to pre-register a victim's email with an unverified password login and later have the victim's OAuth login linked to the attacker's account, granting persistent access. The issue bypasses the requireEmailVerification setting and affects all OAuth and SSO sign-in flows calling handleOAuthUserInfo. The vulnerability is fixed in better-auth 1.6.11 by requiring the local email to be verified before implicit linking.

A vulnerability in the better-auth library's organization plugin allows an attacker to accept an organization invitation without verifying email ownership. This occurs when the application permits unverified email sign-ups and does not enforce email verification on invitation acceptance. An attacker who obtains the invitation ID and registers an unverified account with the victim's email can join the organization with the invited role. The issue is fixed in better-auth version 1.6.11 by requiring email verification on all invitation-related endpoints by default.

A critical vulnerability in the legacy better-auth oidcProvider and mcp plugins allows OAuth refresh-token replay due to missing client authentication on the refresh_token grant. Confidential OAuth clients are not required to provide client_secret when refreshing tokens, enabling an attacker with a valid refresh_token and client_id to mint new access and refresh tokens indefinitely until revoked or expired. The issue is fixed in better-auth version 1.6.11 by enforcing client_secret verification on refresh_token grants and narrowing CORS policies. Migration to the newer @better-auth/oauth-provider package is recommended as it enforces client authentication correctly. Workarounds include forcing all clients to public with PKCE, network ingress restrictions, and manual token revocation, but these do not fully mitigate the risk without patching.