4vulnerabilities
- Critical0 (0.0%)
- High3 (75.0%)
- Medium0 (0.0%)
- Moderate1 (25.0%)
- Low0 (0.0%)
better-auth-oauth-provider
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 3HighAffects 4 versions
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- Critical
- High
- Medium
- Moderate
- Low
- 3 vulnerabilities
- Critical: 0
- High: 2
- Medium: 0
- Moderate: 1
- Low: 0
- 1 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 0
- Low: 0
Vulnerabilities (4)
Known vulnerabilities affecting better-auth-oauth-provider, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-392p-2q2v-4372 | High | Better Auth: OAuth refresh-token rotation forks the token family on concurrent redemption### Am I affected? Users are affected if all of the following are true: - Their project depends on `@better-auth/oauth-provider` at a version `>= 1.6.0, < 1.6.11`, or uses the embedded plugin in `better-auth >= 1.4.8-beta.7, < 1.6.0`. - At least one OAuth client served by their application's authorization server requests the `offline_access` scope, so refresh tokens are minted. - Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refr |
| GitHub (opens in a new tab) | |
| GHSA-7w99-5wm4-3g79 | High | @better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete primitive### Am I affected? Users are affected if all of the following are true: - Their project depends on `@better-auth/oauth-provider` at a version `>= 1.6.0, < 1.6.11`, or uses the embedded plugin in `better-auth >= 1.4.8-beta.7, < 1.6.0`, or enables the legacy `oidc-provider` or `mcp` plugins from `better-auth/plugins`. - Their application exposes `/api/auth/oauth2/token` (or the legacy plugins' `/oauth2/token` and `/mcp/token`) as a token endpoint to OAuth/OIDC clients, including internal MCP clients (Claude Desktop, custom MCP tool callers, AI agents). - Their application has not implemented a |
| GitHub (opens in a new tab) | |
| GHSA-p2fr-6hmx-4528 | Moderate | @better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators### Am I affected? Users are affected if all of the following hold: - Their application depends on `@better-auth/oauth-provider` on any stable `1.6.x` release (the stable line is not patched) or on a pre-release before `1.7.0-beta.4`. - Their application either configures validAudiences` with more than one audience, or it issues JWT access tokens whose `aud` (resource) claim is consumed by their resource servers. - Their resource servers make authorization decisions based on that `aud` or resource value. A deployment with a single `validAudiences` entry (or the default, their server's bas |
| GitHub (opens in a new tab) | |
| GHSA-xr8f-h2gw-9xh6 | High | OAuth 2.1 Provider: Unprivileged users can register OAuth clients### 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 |
| GitHub (opens in a new tab) |
- GHSA-392p-2q2v-4372HighBetter Auth: OAuth refresh-token rotation forks the token family on concurrent redemption
>= 1.6.0, < 1.6.11
### Am I affected? Users are affected if all of the following are true: - Their project depends on `@better-auth/oauth-provider` at a version `>= 1.6.0, < 1.6.11`, or uses the embedded plugin in `better-auth >= 1.4.8-beta.7, < 1.6.0`. - At least one OAuth client served by their application's authorization server requests the `offline_access` scope, so refresh tokens are minted. - Concurrent redemption of the same refresh token is reachable: an SPA shares one refresh token across browser tabs without a mutex, a mobile client retries after a transient failure, an attacker who has stolen a refr
CVE: CVE-2026-53517
- GHSA-7w99-5wm4-3g79High@better-auth/oauth-provider's OAuth authorization-code grant allows concurrent redemption when two token requests race the find-then-delete primitive
>= 1.6.0, < 1.6.11
### Am I affected? Users are affected if all of the following are true: - Their project depends on `@better-auth/oauth-provider` at a version `>= 1.6.0, < 1.6.11`, or uses the embedded plugin in `better-auth >= 1.4.8-beta.7, < 1.6.0`, or enables the legacy `oidc-provider` or `mcp` plugins from `better-auth/plugins`. - Their application exposes `/api/auth/oauth2/token` (or the legacy plugins' `/oauth2/token` and `/mcp/token`) as a token endpoint to OAuth/OIDC clients, including internal MCP clients (Claude Desktop, custom MCP tool callers, AI agents). - Their application has not implemented a
CVE: CVE-2026-53518
- GHSA-p2fr-6hmx-4528Moderate@better-auth/oauth-provider may provide access tokens for unauthorized audiences via unbound resource indicators
>= 1.4.8, < 1.7.0-beta.4
### Am I affected? Users are affected if all of the following hold: - Their application depends on `@better-auth/oauth-provider` on any stable `1.6.x` release (the stable line is not patched) or on a pre-release before `1.7.0-beta.4`. - Their application either configures validAudiences` with more than one audience, or it issues JWT access tokens whose `aud` (resource) claim is consumed by their resource servers. - Their resource servers make authorization decisions based on that `aud` or resource value. A deployment with a single `validAudiences` entry (or the default, their server's bas
CVE: CVE-2026-67332
- GHSA-xr8f-h2gw-9xh6HighOAuth 2.1 Provider: Unprivileged users can register OAuth clients
>= 1.4.8-beta.7, < 1.6.5>= 1.7.0-beta.0, <= 1.7.0-beta.1
### 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
CVE: CVE-2026-41427