The vulnerability exists in the @better-auth/sso plugin's POST /sso/register and POST /sso/update-provider endpoints when skipDiscovery: true is set. These endpoints accept attacker-controlled OIDC endpoint URLs (userInfoEndpoint, tokenEndpoint, jwksEndpoint) without origin validation and persist them. During the OIDC callback, the server fetches these URLs, enabling non-blind SSRF by reflecting fetched response bodies through the user profile. When trustEmailVerified: true is configured, attackers can escalate to account takeover by forging userInfo responses with emailVerified: true and an attacker-chosen email that matches existing accounts, triggering OAuth auto-linking. The fix in version 1.6.11 enforces validation of OIDC endpoint URLs to ensure they are either publicly routable or listed in trustedOrigins, and schema validation is tightened from string to URL format. Workarounds include disabling provider registration, restricting access to registration endpoints, network egress filtering, and disabling trustEmailVerified until upgrade.

An attacker with any valid Better Auth session can exploit this vulnerability to perform non-blind SSRF, reading response bodies from internal or cloud metadata endpoints accessible from the auth server. This includes sensitive infrastructure services and cloud metadata APIs (e.g., AWS IMDS). If trustEmailVerified is enabled, the attacker can escalate the SSRF to account takeover by forging verified email claims that link to existing user accounts, allowing unauthorized access. The vulnerability does not impact availability but compromises confidentiality and integrity of user accounts and internal services.

A fix is available in @better-auth/sso version 1.6.11 and later, which validates OIDC endpoint URLs at registration and update time to prevent SSRF. Users should upgrade to this version promptly. If immediate upgrade is not possible, apply the following workarounds: disable provider self-registration by setting providersLimit to 0; restrict access to POST /sso/register and POST /sso/update-provider endpoints via reverse proxy or IP/user allowlists; implement network-level egress controls blocking access to private IP ranges, link-local addresses, and cloud metadata endpoints; and set trustEmailVerified to false to prevent account takeover escalation. After upgrading, deployments using internal IdPs must add their origins to trustedOrigins to maintain functionality.