GHSA-9h47-pqcx-hjr4

### Am I affected? Users are affected if all of the following are true: - Their application uses `better-auth` at a version below the patched release. - Their application enables `oidcProvider()` from `better-auth/plugins/oidc-provider` or `mcp()` from `better-auth/plugins/mcp` (the mcp plugin delegates to `oidcProvider` and inherits both defaults). - For the algorithm-negotiation impact: relying parties of the application's OIDC server use a JWT verification library that performs algorithm negotiation from the discovery document without pinning to a specific signing algorithm. - For the PKCE impact: the authorization URL is exposed to any party other than the user agent and the application's OP. If the application only uses `@better-auth/oauth-provider` (the canonical replacement) and have not enabled the legacy plugins, it is not affected. The new package's discovery document excludes `none` and its authorize schema rejects `plain` at parse time. Fix: 1. Upgrade to `[email protected]` or later. 2. Migrate from the deprecated `oidcProvider` and `mcp` plugins to `@better-auth/oauth-provider` when feasible. 3. If developers cannot upgrade their applications, see workarounds below. ### Summary The legacy `oidcProvider` and `mcp` plugins exhibit two related defects in their OIDC discovery and authorize surfaces. The discovery document advertises `"none"` in `id_token_signing_alg_values_supported` (and, for `mcp`, in `resource_signing_alg_values_supported` on the OAuth protected-resource metadata). Any relying party that performs algorithm negotiation from this metadata without pinning to a real signing algorithm may accept unsigned tokens. PKCE `plain` is enabled by default. The runtime gate in the authorize handler accepts `code_challenge_method=plain` under this default, and a missing `code_challenge_method` parameter is silently downgraded to `"plain"` before the allowlist check. Discovery advertises `code_challenge_methods_supported: ["S256"]`, contradict