Better Auth SSO CVE-2026-110863

Requires a valid authenticated (low-privilege) account on an application running @better-auth/sso between 1.7.0-rc.2 and 1.7.2 (before 1.7.3), AND the application must permit users to register their own "personal" SSO providers. The attacker must also know a victim's SSO subject identifier or SAML NameID and a legitimate provider's OIDC issuer URL or SAML entity ID to copy. Limiting factors: exploitation is impossible without an authenticated session (PR:L), is gated on the self-service/personal SSO-provider registration feature being enabled (non-default for some deployments), and depends on the vulnerable version range - applications that disable user-registerable providers or run 1.7.3+ are not exposed.

This is a genuine high-priority issue rather than a CVSS-inflated one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H, score 8.6) describes a network-reachable, low-complexity attack requiring only a low-privilege authenticated account (PR:L) and no user interaction, yielding high confidentiality and integrity impact - consistent with full account takeover of arbitrary victim users. The description confirms a concrete logic flaw: account lookup ignores providerId, so an attacker who registers a personal SSO provider mimicking a legitimate provider's OIDC issuer/SAML entity ID can assert a victim's subject/NameID and have a session minted for that victim. No KEV listing and no EPSS score were provided, and no public exploit is referenced, so exploitation signals rest on vendor/VulnCheck disclosure rather than observed in-the-wild activity. The primary limiting factor is that exploitation presupposes an application that enables user-registerable ("personal") SSO providers, which narrows the real-world exposed population below what the raw score implies. Net: real priority for any deployment using the SSO plugin with self-service provider registration, but contingent on that configuration.

An attacker holds a normal authenticated account on an application using @better-auth/sso. They register a personal SSO provider that copies a trusted provider's OIDC issuer (or SAML entity ID) and craft an assertion claiming the victim's subject/NameID; because account lookup ignores providerId, Better Auth matches and issues a session for the victim, granting full account takeover. No public exploit code is referenced, so this reflects the disclosed logic flaw rather than a confirmed in-the-wild technique.