Better Auth SSRF Flaw CVE-2026-53513 (CVSS 9.6) Threatens 19M-Download Auth Library
Do Son 
- CVE: CVE-2026-53513
- CVSS: 9.6 (Critical · CVSSv3)
- Product: better-auth
- Affected: >= 0.1.0, < 1.6.11
- Impact: Better Auth: Server-side request forgery via unvalidated OIDC endpoints on @better-auth/sso provider registration
- Status: No confirmed exploitation yet
- EPSS: 0.2% (30-day)
- Action: See vendor advisory
Running Infra, AppSec, and SOC teams? Tag CVE alerts by team automatically.
Try Team free for 14 daysTL;DR
A critical Better Auth SSRF flaw, tracked as CVE-2026-53513, lets any logged-in user reach internal services. The bug carries a CVSS score of 9.6 and sits in the @better-auth/sso plugin. Maintainers fixed it in version 1.6.11, so upgrade quickly.
Why It Matters
Better Auth is a popular authentication framework for TypeScript. The core npm package draws more than 19 million downloads each month, according to project figures. Therefore, this Better Auth SSRF flaw reaches a wide base of production apps.
The impact runs deep. An attacker with a normal session can read responses from internal endpoints. That includes cloud metadata services like AWS IMDS, plus Redis or admin panels bound to localhost.
How the Attack Works
The flaw lives in the plugin’s provider registration flow. When a developer sets skipDiscovery: true, the POST /sso/register endpoint accepts attacker-supplied OIDC endpoint URLs. Crucially, it stores them without checking their origin.
Later, during the OIDC callback, the server fetches those URLs. It then reflects the response body through the user profile. As a result, the attacker reads internal data directly, which makes this a non-blind SSRF. The same weakness affects POST /sso/update-provider.
Escalation to Account Takeover
Things get worse with one setting. When trustEmailVerified: true is active, a crafted userInfo response can assert a verified email. That triggers OAuth auto-linking against an existing account, which escalates the bug into account takeover.
Affected Versions
The issue affects @better-auth/sso from 0.1.0 up to (but not including) 1.6.11. Any 1.7.0-beta.x release on the pre-release line is also vulnerable. You are exposed only if the sso() plugin sits in your betterAuth plugins array.
By contrast, deployments without the SSO plugin stay safe. No public proof-of-concept or in-the-wild exploitation has been confirmed so far.
Patch and Mitigation Steps
First, upgrade to @better-auth/sso 1.6.11 or later. You can track the fix on the official Better Auth releases page. The patch validates every OIDC endpoint URL and rejects private, loopback, and cloud-metadata targets.
If you cannot patch yet, several workarounds help. Set sso({ providersLimit: 0 }) to block self-registration outright. Alternatively, gate /sso/register at your reverse proxy, and set trustEmailVerified: false to drop the takeover path.
For full technical detail, read the official GitHub security advisory. Above all, patch soon, because this Better Auth SSRF bug hands attackers a direct line into your infrastructure.
Support Our Threat Intelligence
Find our vulnerability reports and weekly recaps helpful? Support our work today and unlock a 100% ad-free reading experience!
Buy Me a Coffee
