GHSA-86j7-9j95-vpqj

### Am I affected? Check each condition. Users are affected when all of the first three hold. - Their application enables the `oidc-provider` plugin or the `mcp` plugin from `better-auth/plugins`. The `mcp` plugin wraps the same provider and carries the same defect. Both are on the migration path to `@better-auth/oauth-provider`, which is not affected. - Their application `better-auth` version is `1.6.12` or earlier on the stable line, or any `1.7.0-beta` build on the pre-release line. Both release lines carry the same defect. - Their application consent page is a client component that reads `redirectURI` from the `authClient.oauth2.consent(...)` response and assigns it to a browser navigation target such as `window.location.href`, `location.assign`, or `location.replace`. Two conditions raise an application's exposure: - It sets `allowDynamicClientRegistration: true`. Client registration is then unauthenticated, so any visitor can plant the malicious client. The default is `false`, which limits planting to authenticated users. - It exposes the consent page to ordinary end users rather than to a restricted operator audience. A developer's application is not affected when any of these hold: - Their application copied the project's `consent-buttons.tsx` demo verbatim. That file reads a `uri` field that this plugin never returns, so its navigation branch never runs and it falls through to an error toast. - Their application completse the consent flow with a server-side redirect, for example a Next.js or Remix server action. Browsers do not follow a `javascript:` URL delivered in a `Location` response header. - Their application uses `@better-auth/oauth-provider` instead of the deprecated `oidc-provider` plugin. Fix: 1. Upgrade to `[email protected]` (stable) or `1.7.0-beta.4` (pre-release). 2. If developers cannot upgrade their applications, see the workarounds below. ### Summary The deprecated `oidc-provider` plugin registers OAuth clients without validatin