Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

CVE-2026-41427 — @better-auth/oauth-provid…

CVE-2026-41427 is a CWE-863 vulnerability in @better-auth/oauth-provider. A fix is available for @better-auth/oauth-provider — see the affected versions and patch details below.

Better Auth OAuth 2.1 Provider: Unprivileged users can register OAuth clients

Also known asGHSA-xr8f-h2gw-9xh6
Published
Apr 24, 2026
Updated
Aug 12, 2026
Affected
2 pkgs
Patched
1 / 2
Exploits
None indexed
Exploitation data as of Sep 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41427.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs12th percentile — riskier than 12% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

30other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@better-auth/oauth-providernpm
952Kdownloads / week

Description

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/[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

2 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@better-auth/oauth-provider≥ 1.4.8-beta.7&&< 1.6.51.6.5npm install @better-auth/oauth-provider@1.6.5
📦npm@better-auth/oauth-provider≥ 1.7.0-beta.0No fix

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @better-auth/oauth-provider, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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 CVE-2026-41427 is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-41427 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-41427. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 n
O3 Security · Impact-Aware SCA

Is CVE-2026-41427 in your dependencies?

O3 Security finds CVE-2026-41427 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

Scan my dependencies How O3 SCA works
CVE-2026-41427: @better-auth/oauth-provid… | O3 Security