GHSA-5rr4-8452-hf4v

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...