Description

@better-auth/sso before 1.6.27 (and before 1.4.8 in the 1.4.x line and before 1.7.0-rc.5 in the 1.7 prerelease line) contains two domain-ownership flaws. When domain verification is disabled, automatic organization assignment accepts unverified provider domains, allowing an authenticated organization owner/administrator to register an SSO provider for an arbitrary domain and have users with matching email domains added to the attacker's organization with default member permissions. When domain verification is enabled, a race condition between the verify-domain and update-provider endpoints can apply completed DNS proof to a different domain; combined with implicit account linking, this can link an attacker-controlled identity provider to an existing user account. Exploitation requires the SSO plugin (and, for the org-assignment path, the organization plugin) with the relevant configuration enabled.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-26T05:18:26.460Z",
  "pubdate": "2026-08-26T05:18:26.460Z",
  "executiveSummary": "The @better-auth/sso package, specifically versions prior to 1.6.27, 1.4.8, and 1.7.0-rc.5, contains two critical domain-ownership vulnerabilities related to SSO provider configuration. These flaws permit unauthorized organization assignment and identity provider account linking. The vulnerabilities stem from improper validation logic when handling automatic organization assignment and race conditions during DNS verification processes.\nImpact includes potential account takeover via implicit account linking and the unauthorized joining of external users to attacker-controlled organizations, granting them default member permissions. Exploitation requires the SSO and organization plugins to be active with specific configurations enabled. Authenticated users with administrative or owner privileges can weaponize these flaws to manipulate organization membership or hijack existing user identities. The risk is high, particularly for multi-tenant environments where domain isolation is essential for security.",
  "technicalDetails": "The vulnerability manifests through two primary vectors within the @better-auth/sso plugin configuration logic. The first vector is an authorization bypass during automatic organization assignment when domain verification is disabled. In this state, the application fails to enforce strict validation on provider domains. Consequently, an authenticated organization owner can register an arbitrary SSO provider domain. When users attempt to authenticate with email addresses matching the attacker-registered domain, the system automatically assigns these users to the attacker's organization, granting them default member permissions without legitimate ownership verification.\nThe second vector involves a race condition vulnerability within the domain verification workflow. When domain verification is explicitly enabled, the system uses a two-step process involving the 'verify-domain' and 'update-provider' endpoints. The flaw exists because the state management between these two operations is not atomic. An attacker can exploit the time window between the completion of a DNS proof and the subsequent provider update. By sending concurrent requests, the attacker can associate a successfully verified DNS proof belonging to one domain with a different, attacker-controlled domain. This bypasses the security check intended to ensure that the entity configuring the SSO provider is indeed the owner of the domain.\nWhen combined with implicit account linking mechanisms, the race condition allows an attacker to manipulate the authentication flow to link an arbitrary identity provider (IdP) to an existing user account. By successfully binding a malicious IdP to a victim's email domain through the race condition, the attacker can facilitate account takeover (ATO) if the victim later initiates an SSO authentication flow that triggers the implicit account linking logic.\nThese vulnerabilities affect @better-auth/sso versions before 1.6.27, 1.4.8 (for the 1.4.x line), and 1.7.0-rc.5 (for the 1.7 prerelease line). Exploitation requires the organization plugin to be enabled and configured alongside the SSO plugin. The network exposure is limited to authenticated users with sufficient permissions to access the organization management interfaces, but the impact of these configuration flaws poses a significant risk to the integrity of user identity and organization boundary enforcement."
}