EUVD-2026-338140

fkie_cve-2026-53513

Better Auth is an authentication and authorization library for TypeScript. Prior to 1.6.11, the @better-auth/sso plugin's POST /sso/register and POST /sso/update-provider endpoints accept attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, store them on the ssoProvider row without origin validation, and fetch them during OIDC callback, allowing non-blind server-side request forgery and possible account linking when trustEmailVerified: true is configured. This issue is fixed in version 1.6.11.

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

Affected: npm: @better-auth/sso

### 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/upd…

Most recent entries from all

EUVD-2026-338140

fkie_cve-2026-53513

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