Server-side Request Forgery (SSRF) Affecting @better-auth/sso package, versions <1.6.11
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-JS-BETTERAUTHSSO-17889831
- published8 Jul 2026
- disclosed7 Jul 2026
- creditvaadata-poyetont Thomas
Introduced: 7 Jul 2026
CVE-2026-53513 (opens in a new tab)How to fix?
Upgrade @better-auth/sso to version 1.6.11 or higher.
Overview
@better-auth/sso is a SSO plugin for Better Auth
Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) via the POST /sso/register and POST /sso/update-provider endpoints when attacker-controlled OIDC endpoint URLs are accepted without proper validation if skipDiscovery: true is set. An attacker can access internal resources or sensitive data by supplying malicious endpoints, leading the server to make requests to arbitrary URLs. If trustEmailVerified: true is enabled and the deployment has accounts with emails overlapping attacker-chosen domains, the attacker can escalate to account takeover by crafting a malicious userInfo response.
Note: This is only exploitable if the SSO plugin is enabled, the attacker has a valid session, and the application allows registration or update of providers with unvalidated endpoints.
Workaround
This vulnerability can be mitigated by disabling provider self-registration (sso({ providersLimit: 0 })), blocking the affected endpoints at the edge or restricting access, implementing network-level egress controls to block access to internal ranges and metadata services, or setting trustEmailVerified: false to prevent account takeover escalation.