GHSA-5rr4-8452-hf4v: @better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints

Am I affected? Users are affected if all of the following are true: - Their application uses @better-auth/sso at a version >= 0.1.0, < 1.6.11 on the stable line, or any 1.7.0-beta.x on the pre-release line. - The sso() plugin is added to their application's betterAuth({ plugins: [...] }) array. - Any user with a valid Better Auth session can reach POST /sso/register (the plugin's default gate accepts any session). For the non-blind SSRF impact (full IAM credential or internal HTTP body exfiltration), no further configuration is required. For the account takeover escalation, additionally: - Developers set sso({ trustEmailVerified: true, ... }). - The developer's application deployment has accounts whose email overlaps with attacker-chosen domains. If developers do not enable the SSO plugin, their application is not affected. Fix: 1. Upgrade to @better-auth/sso@1.6.11 or later. 2. If developers cannot upgrade, see workarounds below. Summary The @better-auth/sso plugin's POST /sso/register endpoint accepts attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, persists them on the ssoProvider row without origin validation, then issues server-side fetches to those URLs during the OIDC callback. The fetched response body is reflected through the user profile, producing a non-blind SSRF reachable by any authenticated session. The same primitive exists on POST /sso/update-provider. Details The schema field types accept bare strings: no .url() validator, no origin gate. The discovery branch (skipDiscovery: false) routes URLs through validateDiscoveryUrl; the skip-discovery branch persists them as-is. At callback time three fetch sites read the stored URLs: validateAuthorizationCode for the token endpoint, betterFetch for the userInfo endpoint, and validateToken for the JWKS endpoint. When trustEmailVerified: true is configured, the attacker can escalate to account linking. A malicious userInfo resp