CVE-2026-110863 in better-auth
Summary
by MITRE • 10/15/2026
Better Auth @better-auth/sso from 1.7.0-rc.2 before 1.7.3 contains an authentication bypass vulnerability that allows authenticated users to sign in as other users by registering a personal SSO provider. Attackers can copy a legitimate provider's OIDC issuer or SAML entity ID and assert a victim's subject or NameID, because account lookup ignores providerId, creating sessions for victim accounts.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within Better Auth versions prior to 1.7.3 represents a critical authentication bypass flaw rooted in the improper validation of Single Sign-On (SSO) parameters during user registration and session establishment processes. This specific weakness allows an authenticated attacker, who possesses valid credentials for their own account, to escalate privileges by impersonating other users within the system. The core technical failure lies in how the application handles identity provider assertions when a new SSO connection is being configured or validated. Specifically, the logic governing account lookup fails to adequately verify that the incoming authentication request corresponds exclusively to the intended user context associated with the authenticated session initiating the action.
From a technical perspective, the flaw manifests through the handling of OpenID Connect (OIDC) and Security Assertion Markup Language (SAML) protocols. An attacker can register a personal SSO provider configuration within their own account settings by copying the issuer URL from a legitimate OIDC provider or the entity ID from a valid SAML service provider. By doing so, they trick the application into accepting assertions signed by these trusted entities but containing identity claims for different users. The critical defect occurs when the system processes the subject identifier in OIDC flows or the NameID attribute in SAML flows; it ignores the providerId context that should tie the assertion to a specific user account. Consequently, if an attacker submits an assertion where the victim's unique subject or NameID is present, the application creates a new session for that victim without requiring their password or multi-factor authentication credentials.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity as defined by common weakness enumerations standards. The attacker exploits the lack of binding between the authenticated user's identity and the SSO provider configuration, effectively bypassing standard access controls. In terms of attack vectors, this behavior is consistent with MITRE ATT&CK technique T1078 Valid Accounts, where an adversary uses legitimate credentials to gain initial access or maintain persistence by impersonating other users within a trusted environment. The ability to assume the identity of another user undermines the fundamental integrity of the authentication system and can lead to severe data breaches if sensitive information is accessible through those accounts.
The operational impact of this vulnerability is significant, as it allows for complete account takeover without any external exploitation or social engineering beyond initial access. Once an attacker gains a foothold in the application with even minimal privileges, they can pivot to compromise high-privilege accounts by simply registering their SSO provider and asserting the target user's identity identifier. This bypasses all other security controls such as password complexity requirements, multi-factor authentication policies, and session management rules designed for legitimate login flows. The resulting unauthorized access enables actions ranging from data exfiltration to lateral movement within connected systems that trust this application’s single sign-on infrastructure.
Mitigation strategies must focus on immediate patching and rigorous validation of SSO parameters. Organizations running affected versions should upgrade Better Auth to version 1.7.3 or later, where the account lookup logic has been corrected to strictly validate provider identifiers against user ownership. In environments where upgrading is not immediately feasible, temporary mitigations include disabling self-service SSO configuration for all users except administrators and implementing strict monitoring of authentication logs for unusual patterns such as rapid registration of new identity providers followed by immediate successful logins with different subject IDs. Additionally, enforcing multi-factor authentication on administrative accounts can reduce the risk of initial compromise that leads to this exploitation chain. Regular security audits should also verify that SSO implementations correctly bind provider configurations to specific user identities and reject assertions where the claimed identity does not match the authenticated session's context.