Summary
@better-auth/sso: SSO provider may allow registration for any org member without a checking their role
Am I affected?
You are affected if all of the following are true:
- You depend on
@better-auth/ssoat any version in>= 1.2.10, < 1.6.11, or any currentnextpre-release. - You enable both
sso()andorganization()plugins. providersLimitis at its default (10) or any non-zero value, so SSO provider registration is enabled for authenticated users.- An organization has non-admin members, or your application can add users to organizations as regular members.
You are at the highest risk if any of these also hold:
- Organization membership can be obtained without a direct admin decision, such as through open invitations, self-serve onboarding, public team joins, or SCIM bulk imports.
organizationProvisioning.defaultRoleororganizationProvisioning.getRolereturnsadminor higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org.domainVerification.enabledisfalse(the default). The malicious provider is immediately usable.
Fix:
- Upgrade to
@better-auth/[email protected]or later. - If you cannot upgrade, see workarounds below.
The SSO plugin's POST /sso/register endpoint lets any member of an organization attach a new SSO provider to that organization. It checks that the caller has a membership row, but it does not check whether the caller has an administrative role for the organization.
This creates an authorization mismatch for the same resource. Other org-linked SSO provider management endpoints treat those providers as admin-managed: list, get, update, and delete require the caller to be an organization owner or admin. The create path is less restrictive, so a regular member can attach an attacker-controlled OIDC or SAML identity provider to an organization they do not administer. After registration, downstream organization provisioning can add IdP-asserted users from /sso/callback/{providerId} into the target organization, defaulting to role member.
Details
This issue does not rely on a separate documentation statement that only admins may create SSO connections. The issue is that Better Auth already enforces an admin boundary for org-linked SSO provider management, but registerSSOProvider does not enforce the same boundary when the provider is first created.
The list, get, update, and delete endpoints in providers.ts gate org-linked SSO providers via isOrgAdmin, which accepts owner or admin. The create path in sso.ts performs only a membership lookup and never inspects member.role. As a result, the endpoint allows a low-privilege organization member to create a provider record that they would not be allowed to view, update, or delete through the companion provider-management endpoints.
The fix introduces a shared hasOrgAdminRole(member) helper (refactored out of isOrgAdmin) and adds the admin check to the registration handler so that registration matches the protections on the read and mutation paths.
Workarounds
If you cannot upgrade immediately:
- Disable user-driven SSO registration entirely: set
sso({ providersLimit: 0 }). Registration throwsFORBIDDENbefore the membership gate. Trade-off: admins also lose self-serve provider creation; provisioning has to go through server-sideauth.api.registerSSOProvider({ headers: serverAdminHeaders, body })calls. - Disable SSO-driven org provisioning: set
sso({ organizationProvisioning: { disabled: true } }). The malicious provider can still be registered, but the SSO callback no longer adds users to the org automatically. Trade-off: legitimate SSO-driven onboarding stops. - Custom
beforehook on/sso/registerthat asserts the caller's role onbody.organizationIdisowneroradmin. This duplicates the patch shape in user code. - Audit existing rows: list
ssoProviderrows whereorganizationId IS NOT NULL, cross-reference eachuserIdwithmember.rolefor that organization, and remove provider rows whose creator is not currentlyowneroradmin. Removing the provider does not auto-remove members it created, so cleanup is two-step.
Credit
Reported by @Nadav0077. The same finding was previously raised in public issue #9133 (2026-04-12).
Impact
- Unauthorized provider configuration within an organization tenant: a regular member writes an SSO provider record on an organization they do not administer.
- Unauthorized organization membership creation: subsequent SSO callbacks can add IdP-asserted users to the target organization at the configured default role.
- Admin creation when configured: if
organizationProvisioning.defaultRoleisadmin, ororganizationProvisioning.getRolereturnsadmin, the issue can create admin-grade users in the target organization without owner consent.
The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access. Typical impact: privilege escalation beyond the intended level.
CVE-2026-53515 has a CVSS score of 7.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.6.11); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in @better-auth/[email protected]. When organizationId is supplied and the organization plugin is enabled, the registerSSOProvider handler now requires the caller to hold the owner or admin role on the target organization. This makes provider creation match the existing protection on the get, update, and delete endpoints.
Frequently Asked Questions
- What is CVE-2026-53515? CVE-2026-53515 is a high-severity improper privilege management vulnerability in @better-auth/sso (npm), affecting versions >= 1.2.10, < 1.6.11. It is fixed in 1.6.11. The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access.
- How severe is CVE-2026-53515? CVE-2026-53515 has a CVSS score of 7.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of @better-auth/sso are affected by CVE-2026-53515? @better-auth/sso (npm) versions >= 1.2.10, < 1.6.11 is affected.
- Is there a fix for CVE-2026-53515? Yes. CVE-2026-53515 is fixed in 1.6.11. Upgrade to this version or later.
- Is CVE-2026-53515 exploitable, and should I be worried? Whether CVE-2026-53515 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-53515 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-53515? Upgrade
@better-auth/ssoto 1.6.11 or later.