GHSA-xr8f-h2gw-9xh6
GHSA-xr8f-h2gw-9xh6 is a CWE-863 vulnerability in @better-auth/oauth-provider. O3 Security confirms whether GHSA-xr8f-h2gw-9xh6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OAuth 2.1 Provider: Unprivileged users can register OAuth clients
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@better-auth/oauth-providernpmDescription
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_consentbecome writable.
Patches
Fixed in @better-auth/[email protected] 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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @better-auth/oauth-provider | ≥ 1.4.8-beta.7&&< 1.6.5 | 1.6.5 |
| 📦npm | @better-auth/oauth-provider | ≥ 1.7.0-beta.0 | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @better-auth/oauth-provider. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @better-auth/oauth-provider to 1.6.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xr8f-h2gw-9xh6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xr8f-h2gw-9xh6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xr8f-h2gw-9xh6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xr8f-h2gw-9xh6 in your dependencies?
O3 detects GHSA-xr8f-h2gw-9xh6 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.