critical

CVE-2026-53513

npm · @better-auth/sso

Summary

@better-auth/sso provider registration has server-side request forgery via unvalidated OIDC endpoints

Severity
critical
CVSS
9.6
EPSS
0.2% (p16)
CWE
CWE-20, CWE-345, CWE-441, CWE-918
Also known as
GHSA-5rr4-8452-hf4v
Published
2026-07-07
Updated
2026-07-07

Advisory details

Am I affected?

Users are affected if all of the following are true:

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:

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 response with emailVerified: true and a chosen email triggers OAuth auto-link against any pre-existing user row with that email, compounding the SSRF into account takeover.

Patches

Fixed in @better-auth/sso@1.6.11. Provider registration (POST /sso/register with skipDiscovery: true) and every POST /sso/update-provider request now validate each supplied OIDC endpoint URL (authorizationEndpoint, tokenEndpoint, userInfoEndpoint, jwksEndpoint, discoveryEndpoint) at registration time. A URL is rejected unless it satisfies one of two conditions:

  1. Its host is publicly routable on the internet, evaluated through the @better-auth/core/utils/host.isPublicRoutableHost gate. RFC 1918 private ranges, RFC 4193 unique-local addresses, link-local addresses (including the cloud-metadata IP 169.254.169.254), loopback, multicast, broadcast, and reserved ranges are rejected, along with cloud-metadata FQDNs.
  2. Its origin is already listed in the application's trustedOrigins configuration. This preserves the documented escape hatch for customers running internal IdPs intentionally on private networks.

The schema also tightens from z.string() to z.url() on those fields, so malformed URLs fail at parse time rather than at fetch time. Deployments running internal IdPs that previously worked must add the IdP's origin to trustedOrigins to keep working after upgrade.

Workarounds

If developers cannot upgrade immediately:

Impact

Credit

Reported by Vaadata.

Resources

References

Related advisories

Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.

Check my repo

Summarize with AI

ChatGPTClaudePerplexity

Sources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.