Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 an external mitigation: a load-balancer-level idempotency cache keyed by code, a database trigger that rejects duplicate token issuance for the same authorization code, or a custom adapter override that performs an atomic compare-and-delete. Fix: 1. Upgrade to @better-auth/oauth-provider@1.6.11 or later. If developers use the legacy plugin paths from better-auth/plugins, upgrade better-auth to 1.6.11 or later. 2. If…
Recommended action: Upgrade to 1.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 offlineaccess 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 refresh token times two requests, or a service worker queues offline requests. If developer applications do not request offlineaccess for any client, no refresh tokens are minted and they are not exposed. Fix: 1. Upgrade to @better-auth/oauth-provider@1.6.11 or later. 2. If developers cannot upgrade, see workarounds below. Summary The OAuth provider's POST /oauth2/token endpoint, on the refreshtoken grant, performs…
Recommended action: Upgrade to 1.6.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 base URL) cannot mint a token for a different audience. The provider rejects any resource outside the allowlist. Such a deployment still does not bind the resource to the authorization grant, so the spec-compliance gap remains even where cross-audience escalation does not apply. Fix: 1. Upgrade to @better-auth/oauth-provider@1.7.0-beta.4 (then 1.7.0), then run the schema migration (npx auth migrate). This is a breaking…
Recommended action: Upgrade to 1.7.0-beta.4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.…
Recommended action: Upgrade to 1.6.5; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.