CVE-2026-53513

### 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/[email protected]` 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 attacke