CVE-2026-114607 in Better Auth
Summary
by MITRE • 10/23/2026
Better Auth is an authentication and authorization library for TypeScript. From 1.4.0-beta.18 until 1.7.7, deployments that enable Magic Link with storeToken set to plain, or with storeToken set to hashed and the global verification.storeIdentifier setting also set to hashed, enable a built-in social or Generic OAuth provider, and use account.storeStateStrategy set to database can accept an OAuth sign-in state value as a Magic Link token. These settings can cause Magic Link verification records and OAuth state to resolve to the same stored identifier, allowing an unauthenticated attacker to start OAuth sign-in for a known email address and redeem the returned state through Magic Link without controlling the mailbox or completing the provider callback. The attacker can obtain a normal session for an existing user, or create an account incorrectly marked as email verified when sign-up is enabled. This issue is fixed in version 1.7.7.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within Better Auth versions ranging from 1.4.0-beta.18 through 1.7.7 represents a critical authentication bypass flaw rooted in the improper separation of security contexts between Magic Link verification and OAuth state management mechanisms. This issue specifically manifests when specific configuration parameters are combined, namely enabling Magic Link with storeToken set to plain or hashed while simultaneously configuring global verification.storeIdentifier as hashed, utilizing an account.storeStateStrategy of database, and employing a built-in social or Generic OAuth provider. Under these conditions, the internal logic fails to distinguish between the unique identifiers generated for magic link sessions and those generated for OAuth state parameters. Consequently, both mechanisms resolve to the same stored identifier within the backend storage system, creating a collision that allows an unauthenticated attacker to exploit this overlap to hijack user accounts or create fraudulent identities without possessing control over the victim's email inbox.
From a technical perspective, the core flaw lies in how identifiers are hashed and stored for different authentication flows. When Magic Link is enabled with storeToken set to plain, the token itself serves as the identifier, whereas when it is set to hashed along with global verification.storeIdentifier being hashed, the system generates a hash of the email or session data to serve as the lookup key. Similarly, OAuth providers generate state parameters that are also stored in the database using the account.storeStateStrategy setting. In version 1.7.7 and earlier, if these configurations overlap, the hashing algorithm produces identical identifiers for both an ongoing Magic Link verification attempt and a pending OAuth authorization request initiated by another party or even self-initiated but intercepted. This lack of namespace isolation means that when an attacker initiates an OAuth sign-in flow with a known email address, they receive a state value which is stored in the database under this shared identifier key. Because the system does not differentiate between the context of Magic Link verification and OAuth state validation, the attacker can subsequently trigger a Magic Link login for that same email address. The system then validates the provided token against the existing record associated with that identifier, effectively accepting the OAuth state value as a valid Magic Link token.
The operational impact of this vulnerability is severe, allowing an unauthenticated actor to gain unauthorized access to existing user accounts or create new accounts that are incorrectly marked as verified. By exploiting the collision between the OAuth state and Magic Link token identifiers, an attacker can bypass the requirement for email ownership verification inherent in both flows. For existing users, this results in a complete authentication bypass where the attacker obtains a valid session cookie without ever receiving or interacting with the magic link sent to the victim's email address. This effectively nullifies the security guarantees provided by two-factor-like mechanisms that rely on out-of-band email delivery. In scenarios where account creation is enabled via Magic Link, an attacker can register new accounts and have them marked as verified immediately upon redemption of the stolen state value, facilitating spamming or further malicious activities under a trusted identity profile. This undermines trust in the platform's user verification processes and exposes sensitive data associated with compromised accounts to unauthorized access.
This vulnerability aligns closely with CWE-287 Improper Authentication, specifically regarding the failure to properly distinguish between different authentication contexts leading to bypass of security controls. It also relates to CWE-613 Insufficient Session Expiration, as the state values remain valid for redemption outside their intended operational window and context. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts, where an attacker uses legitimate credentials or mechanisms in a non-standard way to gain access, and potentially T1528 Steal Application Access Token if the session tokens are subsequently leveraged for API abuse. The attack vector is classified as Network-based with low complexity, requiring only knowledge of the victim's email address and the ability to initiate an OAuth flow against the vulnerable application instance.
Mitigation strategies primarily involve upgrading to Better Auth version 1.7.7 or later, where this identifier collision has been resolved by ensuring distinct namespaces for Magic Link tokens and OAuth state parameters in the database storage layer. For organizations unable to upgrade immediately due to dependency constraints, temporary mitigations include disabling the combination of settings that trigger the vulnerability. Specifically, administrators should avoid using storeToken set to plain with global verification.storeIdentifier hashed while simultaneously enabling social or Generic OAuth providers with account.storeStateStrategy set to database. Alternatively, switching to a different state storage strategy such as in-memory storage for short-lived sessions can prevent the persistent identifier collision from being exploited. Security teams should also audit their authentication configurations to ensure that no other custom implementations replicate this pattern of shared identifiers across distinct security contexts. Regular monitoring of authentication logs for unusual patterns, such as OAuth states being redeemed via login endpoints rather than callback handlers, may help detect exploitation attempts in real-time before significant damage occurs.