Repository navigation
Conversation
Collaborator
|
Hi there @gustavovalverde! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository. This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory |
github-actions
Bot
changed the base branch from
main
to
mikeflame/advisory-improvement-10480
October 21, 2026 18:37
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Upstream evidence supports the version correction, and the remaining wording issue is non-blocking.
1 open issue
What changed in this PR
Updates the OAuth-provider advisory to identify the first patched release in the 1.7 beta line.
Changes:
- Records
1.7.0-beta.2as the fixed version and updates the patch description. - Adds references to the fixing commit and beta release.
| File | Description |
|---|---|
| advisories/github-reviewed/2026/04/GHSA-xr8f-h2gw-9xh6/GHSA-xr8f-h2gw-9xh6.json | Updates the patched-version boundary, description, and references. |
Review effort: Max
| ], | ||
| "summary": "OAuth 2.1 Provider: Unprivileged users can register OAuth clients", | ||
| "details": "### Am I affected?\n\n You're 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't 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 — 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/[email protected]` 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).", | ||
| "details": "### Am I affected?\n\n You're 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't 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 — 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/[email protected]` and, for the 1.7.0 beta line, `1.7.0-beta.2`. Both create endpoints\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).", |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates
Comments
The second range has no patched version.
@better-auth/[email protected]is on npm (published 2026-04-22, after this advisory was published on 2026-04-16) and contains the same fix as 1.6.5. The repository advisory already lists this range as< 1.7.0-beta.2, patched1.7.0-beta.2. The set of affected versions does not change, because no npm version exists between 1.7.0-beta.1 and 1.7.0-beta.2.createOAuthClientEndpointwithout checkingclientPrivileges:/oauth2/create-client: https://github.com/better-auth/better-auth/blob/v1.7.0-beta.1/packages/oauth-provider/src/oauthClient/index.ts#L441-L445/admin/oauth2/create-client: https://github.com/better-auth/better-auth/blob/v1.7.0-beta.1/packages/oauth-provider/src/oauthClient/index.ts#L233-L237assertClientPrivileges(ctx, session, opts, "create")first:git merge-base --is-ancestorshows 5b900a2 is not in v1.7.0-beta.0 or v1.7.0-beta.1, and is in v1.7.0-beta.2 and every later 1.7 tag (beta.3 to beta.10, rc.0 to rc.6, 1.7.0 to 1.7.6).dist/index.mjsin 1.7.0-beta.1 has noclientPrivilegescall withaction: "create". In 1.7.0-beta.2, both create handlers start withawait assertClientPrivileges(ctx, await getSessionFromCtx(ctx), opts, "create").I ran a minimal check based on the advisory text against the published npm packages:
clientPrivilegesreturnsfalsefor every action, and a signed-in user sendsPOST /oauth2/create-clientwith an arbitraryredirect_uris.clientPrivilegescalled withcreatecreatecreateThe 1.7.0-beta.2 changelog does not mention this fix, because the changeset was consumed by the 1.6.5 release on main before the sync. The code and the tarball show that the fix is included.