Summary
Better Auth's OAuth Proxy plugin contains an authentication bypass that can let an unauthenticated attacker sign in as another user by forging encrypted profile state. The risk arises when the proxy shares a global secret, relies on cookie-stored state, and implicitly links accounts using a verified email address.
Better Auth's OAuth Proxy plugin contains an authentication bypass that can let an unauthenticated attacker sign in as another user by forging encrypted profile state. The risk arises when the proxy shares a global secret, relies on cookie-stored state, and implicitly links accounts using a verified email address.
Affected context
The vulnerability occurs in deployments using Better Auth's OAuth Proxy plugin when encrypted profile state is protected with a shared global secret and stored in client-side cookies. It becomes especially risky when the application implicitly links an OAuth identity to an existing account based on a verified email without independently binding the identity to an authenticated user or trusted provider response.
The vulnerability occurs in deployments using Better Auth's OAuth Proxy plugin when encrypted profile state is protected with a shared global secret and stored in client-side cookies. It becomes especially risky when the application implicitly links an OAuth identity to an existing account based on a verified email without independently binding the identity to an authenticated user or trusted provider response.
Exploit preconditions
- Attack surface: OAuth Proxy authentication and profile-linking logic
- Required access: No prior authentication may be required; the attacker must be able to interact with the exposed OAuth sign-in flow
- Trigger point: Processing encrypted profile state during OAuth authentication and account-linking decisions
- Why exploitation is possible: Forged or improperly bound profile data can be accepted as authentic, allowing an attacker-controlled identity to be associated with a victim's verified email
- Attack surface: OAuth Proxy authentication and profile-linking logic
- Required access: No prior authentication may be required; the attacker must be able to interact with the exposed OAuth sign-in flow
- Trigger point: Processing encrypted profile state during OAuth authentication and account-linking decisions
- Why exploitation is possible: Forged or improperly bound profile data can be accepted as authentic, allowing an attacker-controlled identity to be associated with a victim's verified email
Why this happens
The underlying issue is an authentication-boundary failure mapped to CWE-287: Improper Authentication. The OAuth Proxy trusts encrypted, cookie-stored profile state and uses a shared secret in a way that does not sufficiently establish the profile's origin, integrity context, and relationship to the current authentication flow. When implicit email-based linking is performed without robust identity binding and independent verification, attacker-controlled claims may be treated as evidence of an existing user's identity.
The underlying issue is an authentication-boundary failure mapped to CWE-287: Improper Authentication. The OAuth Proxy trusts encrypted, cookie-stored profile state and uses a shared secret in a way that does not sufficiently establish the profile's origin, integrity context, and relationship to the current authentication flow. When implicit email-based linking is performed without robust identity binding and independent verification, attacker-controlled claims may be treated as evidence of an existing user's identity.
Potential impact
- An attacker may authenticate as another user
- Victim accounts could be taken over
- Private account data may be exposed
- Attackers could modify account settings or linked identities
- Unauthorized actions could be performed with the victim's privileges
- An attacker may authenticate as another user
- Victim accounts could be taken over
- Private account data may be exposed
- Attackers could modify account settings or linked identities
- Unauthorized actions could be performed with the victim's privileges
General mitigation guidance
Mitigation generally focuses on strengthening identity binding and reducing trust in client-controlled authentication state.
Common defensive patterns include:
- Bind OAuth state to the initiating browser session, redirect context, and a narrowly scoped server-side record
- Prefer server-side state storage or authenticated, integrity-protected tokens with strict audience, expiry, and context checks
- Avoid using a broadly shared global secret across trust boundaries
- Require explicit, independently verified account-linking confirmation rather than implicit email-based linking
- Validate issuer, audience, authorization context, and verified identity claims against an approved provider configuration
- Apply least privilege to sessions and require reauthentication for sensitive linking or recovery actions
- Rotate secrets and invalidate existing sessions when authentication-boundary tampering is suspected
Mitigation generally focuses on strengthening identity binding and reducing trust in client-controlled authentication state.
Common defensive patterns include:
- Bind OAuth state to the initiating browser session, redirect context, and a narrowly scoped server-side record
- Prefer server-side state storage or authenticated, integrity-protected tokens with strict audience, expiry, and context checks
- Avoid using a broadly shared global secret across trust boundaries
- Require explicit, independently verified account-linking confirmation rather than implicit email-based linking
- Validate issuer, audience, authorization context, and verified identity claims against an approved provider configuration
- Apply least privilege to sessions and require reauthentication for sensitive linking or recovery actions
- Rotate secrets and invalidate existing sessions when authentication-boundary tampering is suspected
How teams detect issues like this
Detection approaches commonly include:
- Static analysis for OAuth flows that trust cookie claims, shared secrets, or client-controlled identity attributes
- Code review checks for implicit account linking based solely on email addresses
- Tests that alter encrypted or signed state, replay state across sessions, and vary issuer or audience claims
- Monitoring for unusual account-linking events, new OAuth identities, concurrent sessions, and sign-ins associated with unexpected providers
- Policy enforcement requiring server-side state binding, explicit linking confirmation, and approved OAuth issuer configurations
Automated security review tools may help identify weak state validation and authentication-boundary violations.
Detection approaches commonly include:
- Static analysis for OAuth flows that trust cookie claims, shared secrets, or client-controlled identity attributes
- Code review checks for implicit account linking based solely on email addresses
- Tests that alter encrypted or signed state, replay state across sessions, and vary issuer or audience claims
- Monitoring for unusual account-linking events, new OAuth identities, concurrent sessions, and sign-ins associated with unexpected providers
- Policy enforcement requiring server-side state binding, explicit linking confirmation, and approved OAuth issuer configurations
Automated security review tools may help identify weak state validation and authentication-boundary violations.
