GHSA-XR8F-H2GW-9XH6

Vulnerability from github – Published: 2026-04-16 22:44 – Updated: 2026-04-27 15:24
VLAI
Summary
OAuth 2.1 Provider: Unprivileged users can register OAuth clients
Details

Am I affected?

You're affected if all of the following are true:

  • Using @better-auth/oauth-provider at version specified below
  • You configured clientPrivileges in the plugin options expecting it to gate who can create OAuth clients
  • The /oauth2/create-client or /admin/oauth2/create-client endpoints are reachable by authenticated users you don't fully trust

If clientPrivileges is not configured, this bug has no security consequence for your deployment


### Summary

The clientPrivileges option documents a create action, but the OAuth client creation endpoints did not invoke the hook before persisting new clients. Deployments that configured clientPrivileges to restrict client registration were not actually restricted — any authenticated user could reach the create endpoints and register an OAuth client with attacker-chosen redirect URIs and metadata.

Non-create operations (read, list, update, delete, rotate) enforced the hook correctly. Only the create path was missing the check.

Impact

  • Unauthorized registration of OAuth clients by any authenticated user, under deployments that expected clientPrivileges to block them.
  • Attacker-controlled redirect_uris on those clients enable phishing flows that present as registered first-party applications.
  • If the SERVER_ONLY admin creation endpoint is also exposed to low-privilege users (a separate deployment misconfiguration), additional sensitive fields including skip_consent become writable.

Patches

Fixed in @better-auth/oauth-provider@1.6.5 Both create endpoints now call the clientPrivileges hook with action "create" before persisting the client record.

Workarounds

If you cannot upgrade immediately:

  • Block the /oauth2/create-client and /admin/oauth2/create-client routes at your reverse proxy or middleware layer for any user who should not be able to register clients.
  • Do not expose the admin creation endpoint (it is SERVER_ONLY by design and should not be reachable by end-user sessions).
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/oauth-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.8-beta.7"
            },
            {
              "fixed": "1.6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/oauth-provider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0-beta.0"
            },
            {
              "last_affected": "1.7.0-beta.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41427"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:44:27Z",
    "nvd_published_at": "2026-04-24T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\n  You\u0027re affected if all of the following are true:\n\n  - Using @better-auth/oauth-provider at version specified below \n  - You configured clientPrivileges in the plugin options expecting it to gate who can create OAuth clients\n  - The /oauth2/create-client or /admin/oauth2/create-client endpoints are reachable by authenticated users you don\u0027t fully trust\n\n  If clientPrivileges is not configured, this bug has no security consequence for your deployment\n\n  ---\n  ### Summary\n\n  The clientPrivileges option documents a create action, but the OAuth client creation endpoints did not invoke the hook before persisting new clients. Deployments that configured clientPrivileges to restrict client registration were not actually restricted \u2014 any authenticated user could reach the create endpoints and register an OAuth client with attacker-chosen redirect URIs and metadata.\n\n Non-create operations (read, list, update, delete, rotate) enforced the hook correctly. Only the create path was missing the check.\n\n### Impact\n\n  - Unauthorized registration of OAuth clients by any authenticated user, under deployments that expected clientPrivileges to block them.\n  - Attacker-controlled redirect_uris on those clients enable phishing flows that present as registered first-party applications.\n  - If the SERVER_ONLY admin creation endpoint is also exposed to low-privilege users (a separate deployment misconfiguration), additional sensitive fields including `skip_consent` become writable.\n\n### Patches\n\nFixed in `@better-auth/oauth-provider@1.6.5` Both create endpoints now call the clientPrivileges hook with action \"create\" before persisting the client record.\n\n### Workarounds\n\n  If you cannot upgrade immediately:\n\n  - Block the /oauth2/create-client and /admin/oauth2/create-client routes at your reverse proxy or middleware layer for any user who should not be able to register clients.\n  - Do not expose the admin creation endpoint (it is SERVER_ONLY by design and should not be reachable by end-user sessions).",
  "id": "GHSA-xr8f-h2gw-9xh6",
  "modified": "2026-04-27T15:24:29Z",
  "published": "2026-04-16T22:44:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-xr8f-h2gw-9xh6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41427"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:L/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OAuth 2.1 Provider: Unprivileged users can register OAuth clients"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…