How severe is CVE-2026-53513?

CVE-2026-53513 has a CVSS score of 9.6/10, rated CRITICAL. Immediate patching is strongly recommended.

Which packages are affected by CVE-2026-53513?

CVE-2026-53513 affects the following packages: @better-auth/sso (npm). Ecosystems affected: npm.

How do I fix CVE-2026-53513?

Update @better-auth/sso to 1.6.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-53513 is resolved across your whole dependency graph.

How do I detect CVE-2026-53513 in my npm dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @better-auth/sso, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate CVE-2026-53513 if there is no patch (or I can't update yet)?

Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Is CVE-2026-53513 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-53513 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for CVE-2026-53513?

CVE-2026-53513 has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 15th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is CVE-2026-53513?

CVE-2026-53513 is classified as Improper Input Validation (CWE-20), CWE-345 (CWE-345), CWE-441 (CWE-441), Server-Side Request Forgery (SSRF) (CWE-918). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was CVE-2026-53513 published, and has it been updated?

CVE-2026-53513 was published on July 15, 2026 and was last updated on August 12, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

📦

📦 npm

Not in CISA KEV

CRITICAL severity

CVE-2026-53513 — @better-auth/sso

CRITICALFix: better-auth/better-auth@37f60cb

CVE-2026-53513 is a critical-severity (CVSS 9.6) Improper Input Validation vulnerability in @better-auth/sso. A fix is available for @better-auth/sso — see the affected versions and patch details below.

Better Auth: Server-side request forgery via unvalidated OIDC endpoints on @better-auth/sso provider registration

Also known asGHSA-5rr4-8452-hf4v

Published

Jul 15, 2026

Updated

Aug 12, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Oct 12, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

A successful exploit gives an attacker total control of the affected component, not partial access.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-53513.

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs15th percentile — riskier than 15% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-53513 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 388,997 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

19other npm packages depend on this — each one inherits the vulnerability until it's patched upstream

@better-auth/ssonpm

1.1Mdownloads / week

Description

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:

Upgrade to @better-auth/[email protected] or later.
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/[email protected]. 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:

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

Disable provider self-registration: set sso({ providersLimit: 0 }). The limit is enforced before the schema branch, blocking every /sso/register regardless of skipDiscovery.
Reverse-proxy gate: block POST /sso/register and POST /sso/update-provider at the edge, or restrict to a denylist of source IPs and a small admin user list.
Network-level egress controls: block egress from the auth server to RFC 1918, RFC 4193, link-local ranges (169.254.0.0/16, fe80::/10), and the cloud-metadata FQDN list at the firewall or VPC level. AWS users should additionally enforce IMDSv2 (HttpTokens: required).
Set trustEmailVerified: false until upgrade. This caps the impact at non-blind SSRF and removes the account-takeover escalation, but does not stop the SSRF.

Impact

Server-Side Request Forgery (non-blind): the attacker reads response bodies from any HTTP endpoint reachable from the auth server, including cloud metadata services (AWS IMDS, GCP metadata FQDN), internal-only APIs, and infrastructure services such as Redis or admin panels bound to localhost.
Account takeover (when trustEmailVerified: true): the attacker mints a malicious userInfo response asserting emailVerified: true for an arbitrary email, triggering OAuth auto-link against pre-existing user rows.

Credit

Reported by Vaadata.

Resources

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
📦npm	`@better-auth/sso`	≥ 0.1.0&&< 1.6.11	1.6.11`npm install @better-auth/sso@1.6.11`

Affected Products

2 products · 2 configurations

Application

better authbetter-auth

≥ 0.1.0 && < 1.6.11

range

Application

better-auth\/ssobetter-auth

< 1.6.11

range

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @better-auth/sso, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @better-auth/sso to 1.6.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-53513 is resolved across your whole dependency graph.
Workarounds
Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### 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,