GHSA-XR8F-H2GW-9XH6
Vulnerability from github – Published: 2026-04-16 22:44 – Updated: 2026-04-27 15:24Am 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_consentbecome 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).
{
"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"
}
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.