{"id":"CVE-2026-53515","aliases":["EUVD-2026-44740","GHSA-gv74-j8m3-fg5f"],"status":"published","title":"Better Auth: Privilege escalation via SSO provider registration: missing admin role check in @better-auth/sso","description":"Better Auth is an authentication and authorization library for TypeScript. From 1.2.10 until 1.6.11, the @better-auth/sso plugin's POST /sso/register endpoint lets any organization member attach a new SSO provider to that organization because registerSSOProvider checks only for a membership row and does not require an owner or admin role, allowing attacker-controlled OIDC or SAML providers to drive /sso/callback/{providerId} organization provisioning. This issue is fixed in version 1.6.11.","severity":{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00426,"percentile":0.37173,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-269","CWE-285","CWE-863"],"published":"2026-07-15T17:27:00Z","modified":"2026-10-28T02:30:57Z","fixes":[{"ecosystem":"npm","package":"@better-auth/sso","fixed_in":["1.6.11"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@better-auth/sso","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.2.10"},{"fixed":"1.6.11"}]}]},{"source":"osv","ecosystem":"npm","package":"@better-auth/sso","ranges":[{"type":"SEMVER","events":[{"introduced":"1.2.10"},{"fixed":"1.6.11"}]}]}],"products":[{"vendor":"@better-auth","product":"sso"},{"vendor":"better-auth","product":"better-auth"},{"vendor":"better-auth","product":"better-auth\\/sso"},{"vendor":"better-auth","product":"better_auth"}],"references":[{"url":"https://github.com/better-auth/better-auth/security/advisories/GHSA-gv74-j8m3-fg5f","tags":["x_refsource_CONFIRM","Mitigation","Vendor Advisory","advisory","web"]},{"url":"https://github.com/better-auth/better-auth/pull/9220","tags":["x_refsource_MISC","Issue Tracking","Patch","fix","web"]},{"url":"https://github.com/better-auth/better-auth/commit/86765f1597378f5c3deed1b80ca91faac0a6bf00","tags":["x_refsource_MISC","Patch","fix","web"]},{"url":"https://github.com/better-auth/better-auth/releases/tag/v1.6.11","tags":["x_refsource_MISC","Release Notes","web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-53515","tags":["advisory"]},{"url":"https://github.com/better-auth/better-auth/issues/9133","tags":["web"]},{"url":"https://github.com/advisories/GHSA-gv74-j8m3-fg5f"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/53xxx/CVE-2026-53515.json","tags":["advisory"]},{"url":"https://github.com/better-auth/better-auth","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-53515","title":"Better Auth: Privilege escalation via SSO provider registration: missing admin role check in @better-auth/sso","description":"Better Auth is an authentication and authorization library for TypeScript. From 1.2.10 until 1.6.11, the @better-auth/sso plugin's POST /sso/register endpoint lets any organization member attach a new SSO provider to that organization because registerSSOProvider checks only for a membership row and does not require an owner or admin role, allowing attacker-controlled OIDC or SAML providers to drive /sso/callback/{providerId} organization provisioning. This issue is fixed in version 1.6.11.","status":"published","published":"2026-07-15T17:27:00.291Z","modified":"2026-07-15T19:30:08.165Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-269","CWE-285","CWE-863"],"updated_at":"2026-11-02T14:20:00.11477Z"}],"euvd":[{"id":"EUVD-2026-44740","description":"Better Auth is an authentication and authorization library for TypeScript. From 1.2.10 until 1.6.11, the @better-auth/sso plugin's POST /sso/register endpoint lets any organization member attach a new SSO provider to that organization because registerSSOProvider checks only for a membership row and does not require an owner or admin role, allowing attacker-controlled OIDC or SAML providers to drive /sso/callback/{providerId} organization provisioning. This issue is fixed in version 1.6.11.","status":"published","published":"2026-07-15T17:27:00Z","modified":"2026-07-15T19:30:08Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T18:19:52.35951Z"}],"ghsa":[{"id":"GHSA-gv74-j8m3-fg5f","title":"@better-auth/sso: SSO provider may allow registration for any org member without a checking their role","description":"### Am I affected?\n\nYou are affected if all of the following are true:\n\n- You depend on `@better-auth/sso` at any version in `\u003e= 1.2.10, \u003c 1.6.11`, or any current `next` pre-release.\n- You enable both `sso()` and `organization()` plugins.\n- `providersLimit` is at its default (`10`) or any non-zero value, so SSO provider registration is enabled for authenticated users.\n- An organization has non-admin members, or your application can add users to organizations as regular members.\n\nYou are at the highest risk if any of these also hold:\n\n- 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.\n- `organizationProvisioning.defaultRole` or `organizationProvisioning.getRole` returns `admin` or higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org.\n- `domainVerification.enabled` is `false` (the default). The malicious provider is immediately usable.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If you cannot upgrade, see workarounds below.\n\n### Summary\n\nThe 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.\n\nThis 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`.\n\n### Details\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. 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.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Disable user-driven SSO registration entirely**: set `sso({ providersLimit: 0 })`. Registration throws `FORBIDDEN` before the membership gate. Trade-off: admins also lose self-serve provider creation; provisioning has to go through server-side `auth.api.registerSSOProvider({ headers: serverAdminHeaders, body })` calls.\n- **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.\n- **Custom `before` hook on `/sso/register`** that asserts the caller's role on `body.organizationId` is `owner` or `admin`. This duplicates the patch shape in user code.\n- **Audit existing rows**: list `ssoProvider` rows where `organizationId IS NOT NULL`, cross-reference each `userId` with `member.role` for that organization, and remove provider rows whose creator is not currently `owner` or `admin`. Removing the provider does not auto-remove members it created, so cleanup is two-step.\n\n### Impact\n\n- **Unauthorized provider configuration within an organization tenant**: a regular member writes an SSO provider record on an organization they do not administer.\n- **Unauthorized organization membership creation**: subsequent SSO callbacks can add IdP-asserted users to the target organization at the configured default role.\n- **Admin creation when configured**: if `organizationProvisioning.defaultRole` is `admin`, or `organizationProvisioning.getRole` returns `admin`, the issue can create admin-grade users in the target organization without owner consent.\n\n### Credit\n\nReported by @Nadav0077. The same finding was previously raised in public issue [#9133](https://github.com/better-auth/better-auth/issues/9133) (2026-04-12).","status":"published","published":"2026-07-20T21:06:17Z","modified":"2026-07-20T21:06:18Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-269","CWE-285","CWE-863"],"updated_at":"2026-11-02T14:40:47.245721Z"}],"nvd":[{"id":"CVE-2026-53515","description":"Better Auth is an authentication and authorization library for TypeScript. From 1.2.10 until 1.6.11, the @better-auth/sso plugin's POST /sso/register endpoint lets any organization member attach a new SSO provider to that organization because registerSSOProvider checks only for a membership row and does not require an owner or admin role, allowing attacker-controlled OIDC or SAML providers to drive /sso/callback/{providerId} organization provisioning. This issue is fixed in version 1.6.11.","status":"published","published":"2026-07-15T18:16:47.817Z","modified":"2026-07-21T15:38:36.12Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-269","CWE-285","CWE-863"],"updated_at":"2026-11-02T14:12:29.879716Z"}],"osv":[{"id":"CVE-2026-53515","title":"Better Auth: Privilege escalation via SSO provider registration: missing admin role check in @better-auth/sso","description":"Better Auth is an authentication and authorization library for TypeScript. From 1.2.10 until 1.6.11, the @better-auth/sso plugin's POST /sso/register endpoint lets any organization member attach a new SSO provider to that organization because registerSSOProvider checks only for a membership row and does not require an owner or admin role, allowing attacker-controlled OIDC or SAML providers to drive /sso/callback/{providerId} organization provisioning. This issue is fixed in version 1.6.11.","status":"published","published":"2026-07-15T17:27:00.291Z","modified":"2026-10-28T02:30:57.03548444Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-269","CWE-285","CWE-863"],"updated_at":"2026-11-02T15:45:08.132336Z"},{"id":"GHSA-gv74-j8m3-fg5f","title":"@better-auth/sso: SSO provider may allow registration for any org member without a checking their role","description":"### Am I affected?\n\nYou are affected if all of the following are true:\n\n- You depend on `@better-auth/sso` at any version in `\u003e= 1.2.10, \u003c 1.6.11`, or any current `next` pre-release.\n- You enable both `sso()` and `organization()` plugins.\n- `providersLimit` is at its default (`10`) or any non-zero value, so SSO provider registration is enabled for authenticated users.\n- An organization has non-admin members, or your application can add users to organizations as regular members.\n\nYou are at the highest risk if any of these also hold:\n\n- 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.\n- `organizationProvisioning.defaultRole` or `organizationProvisioning.getRole` returns `admin` or higher for SSO-provisioned users. The bug then becomes unauthorized admin creation in the org.\n- `domainVerification.enabled` is `false` (the default). The malicious provider is immediately usable.\n\nFix:\n\n1. Upgrade to `@better-auth/sso@1.6.11` or later.\n2. If you cannot upgrade, see workarounds below.\n\n### Summary\n\nThe 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.\n\nThis 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`.\n\n### Details\n\nThis 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.\n\nThe 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.\n\nThe 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.\n\n### Patches\n\nFixed in `@better-auth/sso@1.6.11`. 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.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- **Disable user-driven SSO registration entirely**: set `sso({ providersLimit: 0 })`. Registration throws `FORBIDDEN` before the membership gate. Trade-off: admins also lose self-serve provider creation; provisioning has to go through server-side `auth.api.registerSSOProvider({ headers: serverAdminHeaders, body })` calls.\n- **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.\n- **Custom `before` hook on `/sso/register`** that asserts the caller's role on `body.organizationId` is `owner` or `admin`. This duplicates the patch shape in user code.\n- **Audit existing rows**: list `ssoProvider` rows where `organizationId IS NOT NULL`, cross-reference each `userId` with `member.role` for that organization, and remove provider rows whose creator is not currently `owner` or `admin`. Removing the provider does not auto-remove members it created, so cleanup is two-step.\n\n### Impact\n\n- **Unauthorized provider configuration within an organization tenant**: a regular member writes an SSO provider record on an organization they do not administer.\n- **Unauthorized organization membership creation**: subsequent SSO callbacks can add IdP-asserted users to the target organization at the configured default role.\n- **Admin creation when configured**: if `organizationProvisioning.defaultRole` is `admin`, or `organizationProvisioning.getRole` returns `admin`, the issue can create admin-grade users in the target organization without owner consent.\n\n### Credit\n\nReported by @Nadav0077. The same finding was previously raised in public issue [#9133](https://github.com/better-auth/better-auth/issues/9133) (2026-04-12).","status":"published","published":"2026-07-20T21:06:17Z","modified":"2026-07-20T21:15:24.421809522Z","cvss":[{"version":"3.1","score":7.1,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N","level":"high"}],"cwes":["CWE-269","CWE-285","CWE-863"],"updated_at":"2026-11-02T15:46:48.191583Z"}]}}