CVE-2026-110862 in Better Auth
Summary
by MITRE • 10/15/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within Better Auth versions prior to 1.7.7 represents a critical authentication bypass flaw rooted in the improper separation of security contexts between OAuth flows and Magic Link mechanisms. This issue arises from a fundamental design oversight where state parameters generated during an Open Authorization process are not sufficiently isolated from tokens used for passwordless login verification. Specifically, the application fails to validate that a token presented for Magic Link authentication was originally issued by the Magic Link service itself, rather than being derived from or reused as part of an OAuth handshake. This lack of strict origin validation allows attackers to exploit the shared handling of state-like identifiers across different authentication pathways, creating a bridge between unauthenticated access and privileged user sessions.
From a technical perspective, the exploitation vector involves a sequence where an attacker initiates an OAuth sign-in process using the email address of a target victim. During this standard OAuth flow, the provider generates a unique state parameter to ensure the integrity of the callback and prevent cross-site request forgery attacks. Instead of completing the OAuth handshake through legitimate channels, the attacker intercepts or predicts this state value and submits it directly to the Magic Link verification endpoint. Because the backend logic incorrectly treats any validly formatted state token as a potential Magic Link authentication credential, the system accepts the input without verifying its provenance. This results in the application granting access based on credentials that were never intended for such use, effectively bypassing the multi-step verification process required for secure login.
The operational impact of this vulnerability is severe, allowing unauthenticated attackers to assume the identity of other users with minimal effort. By successfully submitting a reused OAuth state value as a Magic Link token, an attacker can either gain immediate access to an existing user session or create new accounts that are falsely marked as email-verified. This capability undermines the core trust model of the authentication system, enabling unauthorized data access, privilege escalation, and potential account takeover. Furthermore, because the attack relies on reusing values generated during legitimate OAuth flows, it may evade basic anomaly detection systems that do not monitor for cross-flow token reuse patterns. The ability to create falsely verified accounts also poses a long-term risk, as these compromised identities can be used for further malicious activities such as spamming or phishing campaigns with higher credibility than unverified accounts.
This flaw aligns closely with CWE-287, which describes Improper Authentication, specifically the failure to properly verify credentials before granting access. It also maps to MITRE ATT&CK technique T1078, Valid Accounts, where adversaries leverage legitimate user credentials or identities to maintain persistence and evade detection. The root cause is a classic case of insufficient input validation regarding token origin and context binding. To mitigate this risk, developers must enforce strict separation between OAuth state parameters and Magic Link tokens by implementing distinct namespaces or prefixes for each type of credential. Additionally, adding cryptographic signatures that bind the token to its specific authentication flow ensures that even if an attacker obtains a valid state value from one flow, it cannot be repurposed in another. Upgrading to version 1.7.7 or later is essential as these updates include patches that enforce proper validation logic and prevent cross-flow token reuse. Organizations should also implement monitoring for unusual patterns of authentication requests involving rapid succession of OAuth initiations followed by Magic Link verifications using the same identifiers, providing an additional layer of defense against exploitation attempts.