better-auth vulnerabilities

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.

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.

Better-auth before version 1.4.9 contains a two-factor authentication bypass vulnerability when session.cookieCache is enabled. Attackers with valid primary credentials can access authenticated routes without completing second-factor verification by exploiting premature session caching.

better-auth before version 1.6.11 contains insecure cryptographic defaults in the oidcProvider and mcp plugins that advertise the none algorithm and accept plain PKCE by default. Attackers can exploit algorithm negotiation to accept unsigned tokens or intercept authorization codes when PKCE plain is used instead of the required S256 method.

Better-auth before version 1.6.2 fails to validate the OAuth state parameter against the stored nonce when using cookie-backed state storage without PKCE. Attackers can forge the state parameter and supply an attacker-controlled authorization code to create authenticated sessions bound to the attacker's external identity or persistently link attacker accounts to victim profiles.

better-auth versions before 1.6.11 fail to delete cached sessions when removing users via admin, anonymous, or SCIM endpoints when secondaryStorage is configured and storeSessionInDatabase is false. Attackers can reuse deleted user session tokens to maintain authentication for up to seven days after account deletion.

better-auth before version 1.6.13 (and pre-release builds 1.7.0-beta.0 through 1.7.0-beta.3) fail to validate the scheme of redirect_uris registered via the deprecated oidc-provider plugin and the mcp plugin. An attacker can register an OAuth client with a javascript: redirect_uri, which the authorization server later returns unchanged in the consent response. If the deployment's consent page navigates the browser to the returned redirectURI, the attacker's JavaScript executes in the authorization-server origin, exposing the victim's session and enabling account takeover.

better-auth SCIM versions from 1.5.0 before 1.7.0-beta.4 fail to bind non-organization SCIM providers to their creator by default, allowing authenticated users to manage other users' providers. Attackers can regenerate SCIM bearer tokens, invalidate legitimate tokens, and authenticate to SCIM API routes with the attacker-controlled token.

better-auth versions >= 1.1.3 and < 1.6.22 (and pre-release versions >= 1.7.0-beta.0 and < 1.7.0-beta.10) are vulnerable to account takeover via pre-account hijacking on magic-link and email-OTP sign-in when open email/password registration is enabled. An attacker registers an account with the victim's email address and an attacker-chosen password; the account remains unverified. When the legitimate owner later signs in via the magic-link or email-OTP passwordless flow, the account is marked verified without removing the pre-existing password or revoking existing sessions, so the attacker's password remains valid, granting persistent access to the victim's account. Fixed in 1.6.22 and 1.7.0-beta.10.

better-auth versions after v0.0.2 and before 1.1.16 contain a reflected XSS vulnerability on the /api/auth/error page, where the 'error' URL parameter is reflected as HTML without proper neutralization. An attacker can coerce a user into visiting a specially-crafted URL to execute arbitrary JavaScript in the user's browser.

better-auth before version 1.1.20 contains a bypass vulnerability in trustedOrigins validation logic affecting absolute URLs and wildcard domains. Attackers can craft malicious callbackURL parameters that pass origin checks and trigger open redirects to steal sensitive tokens for account takeover.

better-auth versions greater than 1.3.34 and before 1.4.0 contain a vulnerability in the multi-session plugin's /sign-out after-hook, which trusts raw multi-session cookies and forwards extracted values to internalAdapter.deleteSessions without verifying the cookie signature. An attacker can supply a forged _multi-* cookie to trigger deletion of arbitrary session tokens.

Better Auth versions 1.6.0 through 1.6.11 have a vulnerability in the POST /oauth2/token endpoint for the authorization_code grant. The authorization code is checked and deleted in a non-atomic find-then-delete sequence, allowing two concurrent requests to read the same code and mint independent access, refresh, and ID tokens.

Better Auth library for TypeScript has a vulnerability in the POST /oauth2/token endpoint for the refresh_token grant. A non-atomic read, validate, revoke, and mint sequence allows concurrent requests with the same parent refresh token to bypass the revocation check and create forked refresh-token families.

A vulnerability in the Better Auth library allows unauthorized linking of OAuth accounts with existing user accounts. The auto-link gate accepts email verification from the OAuth provider without checking if the local user's email is verified. An attacker can register an account with the victim's email and then link it to the victim's OAuth identity.

Vulnerability in Better Auth library versions 1.2.10 through 1.6.11. The POST /sso/register endpoint of the @better-auth/sso plugin allows any organization member to attach a new SSO provider because registerSSOProvider only checks for a membership row and does not require an owner or admin role. This allows an attacker to control OIDC or SAML providers and drive organization provisioning via /sso/callback/{providerId}.

Better Auth library for TypeScript has a vulnerability in the organization plugin that allows a user with an unverified session for the invited email address to accept an invitation after obtaining the invitation ID. The issue affects versions prior to 1.6.11 and versions 1.6.14 and later when invitation IDs are obtainable outside the invited mailbox and requireEmailVerificationOnInvitation: true is not enabled.

A vulnerability in Better Auth versions 1.6.0 through 1.6.11 allows an authenticated attacker who knows a valid user_code to hijack a pending device authorization session. The issue stems from missing ownership checks in GET /device, POST /device/approve, and POST /device/deny endpoints.

Better Auth, a TypeScript authentication library, has a vulnerability in its HTTP rate limiter that keys requests by the exact textual IP address from the x-forwarded-for header. An IPv6 attacker can bypass rate limits by rotating through different source addresses or varying the textual encoding of a single address.