Summary
Better Auth contains an authentication bypass in which OAuth state values can be reused as Magic Link verification tokens. An unauthenticated attacker may use this confusion to obtain a session as another user or create an account that is incorrectly marked as email verified.
Better Auth contains an authentication bypass in which OAuth state values can be reused as Magic Link verification tokens. An unauthenticated attacker may use this confusion to obtain a session as another user or create an account that is incorrectly marked as email verified.
Affected context
The issue may affect Better Auth deployments that support both OAuth sign-in and Magic Link authentication, where values produced during an OAuth flow are accepted by the Magic Link verification path. Risk increases when the two flows do not use distinct, purpose-bound token types and when identity or email-verification checks are not independently enforced.
The issue may affect Better Auth deployments that support both OAuth sign-in and Magic Link authentication, where values produced during an OAuth flow are accepted by the Magic Link verification path. Risk increases when the two flows do not use distinct, purpose-bound token types and when identity or email-verification checks are not independently enforced.
Exploit preconditions
- Attack surface: OAuth sign-in and Magic Link verification endpoints
- Required access: No prior authentication is required; the attacker needs to initiate an OAuth flow and submit values to the authentication service
- Trigger point: Magic Link token verification after an OAuth state value has been issued
- Why exploitation is possible: The service accepts an OAuth state value in a context intended for Magic Link authentication, allowing authentication context to be confused across distinct flows
- Attack surface: OAuth sign-in and Magic Link verification endpoints
- Required access: No prior authentication is required; the attacker needs to initiate an OAuth flow and submit values to the authentication service
- Trigger point: Magic Link token verification after an OAuth state value has been issued
- Why exploitation is possible: The service accepts an OAuth state value in a context intended for Magic Link authentication, allowing authentication context to be confused across distinct flows
Why this happens
The underlying bug is an authentication design flaw in which an OAuth state value is treated as a valid Magic Link token. Authentication artifacts from separate protocols are not sufficiently differentiated or bound to their intended purpose, user, and flow.
This maps to CWE-287: Improper Authentication, because the application may accept proof that does not validly authenticate the claimed user or verify the claimed email address.
The underlying bug is an authentication design flaw in which an OAuth state value is treated as a valid Magic Link token. Authentication artifacts from separate protocols are not sufficiently differentiated or bound to their intended purpose, user, and flow.
This maps to CWE-287: Improper Authentication, because the application may accept proof that does not validly authenticate the claimed user or verify the claimed email address.
Potential impact
- An attacker may obtain a session associated with another user's identity
- Unauthorized access to account-protected functionality could occur
- Accounts may be created or modified with falsely verified email status
- User data, account settings, or connected integrations could be exposed or changed
- Downstream trust decisions based on authentication or email verification may be bypassed
- An attacker may obtain a session associated with another user's identity
- Unauthorized access to account-protected functionality could occur
- Accounts may be created or modified with falsely verified email status
- User data, account settings, or connected integrations could be exposed or changed
- Downstream trust decisions based on authentication or email verification may be bypassed
General mitigation guidance
Mitigation generally focuses on keeping authentication flows cryptographically and logically separate.
Common defensive patterns include:
- Use distinct, purpose-bound token formats and validation paths for OAuth state and Magic Link tokens
- Bind OAuth state to the initiating browser session, expected redirect, provider, and transaction context
- Validate token purpose, audience, subject, expiration, and single-use status before creating a session
- Require independent proof of control for email-link authentication rather than trusting OAuth state values
- Avoid treating client-supplied or cross-flow values as authenticated identity assertions
- Apply least privilege to sessions and require additional verification for sensitive account changes
Mitigation generally focuses on keeping authentication flows cryptographically and logically separate.
Common defensive patterns include:
- Use distinct, purpose-bound token formats and validation paths for OAuth state and Magic Link tokens
- Bind OAuth state to the initiating browser session, expected redirect, provider, and transaction context
- Validate token purpose, audience, subject, expiration, and single-use status before creating a session
- Require independent proof of control for email-link authentication rather than trusting OAuth state values
- Avoid treating client-supplied or cross-flow values as authenticated identity assertions
- Apply least privilege to sessions and require additional verification for sensitive account changes
How teams detect issues like this
Organizations can look for authentication-flow confusion through:
- Static analysis and code review searches for shared token parsers or validators across OAuth and Magic Link paths
- Review of whether state values are purpose-bound, single-use, session-bound, and independently validated
- Tests that submit artifacts from one authentication flow to another and confirm rejection
- Monitoring for unusual sequences involving OAuth initiation followed by Magic Link verification
- Policy checks requiring explicit token audiences, expiration handling, and identity binding
Automated security testing and code review tools may help identify shared validation logic or missing flow-separation controls.
Organizations can look for authentication-flow confusion through:
- Static analysis and code review searches for shared token parsers or validators across OAuth and Magic Link paths
- Review of whether state values are purpose-bound, single-use, session-bound, and independently validated
- Tests that submit artifacts from one authentication flow to another and confirm rejection
- Monitoring for unusual sequences involving OAuth initiation followed by Magic Link verification
- Policy checks requiring explicit token audiences, expiration handling, and identity binding
Automated security testing and code review tools may help identify shared validation logic or missing flow-separation controls.
