Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
Miggo AIRoot Cause AnalysisThe vulnerability lies in the insecure default configurations of the oidcProvider and mcp plugins in better-auth. Specifically, two main issues were identified. First, the discovery endpoints for both plugins advertised alg=none as a supported algorithm for token signing. This could allow a malicious relying party to trick the system into accepting unsigned tokens, completely bypassing cryptographic verification. The functions getMetadata, getMCPProviderMetadata, and getMCPProtectedResourceMetadata were responsible for generating this metadata.
Second, the authorization endpoints for both plugins accepted the plain method for Proof Key for Code Exchange (PKCE) by default. The authorize and authorizeMCPOAuth functions would even silently default to plain if the code_challenge_method parameter was omitted from the request. This is a significant security risk, as the plain method offers no protection against authorization code interception. If an attacker could gain access to the authorization code (e.g., through a compromised browser or proxy logs), they could use it to obtain an access token and impersonate the user. The oidcProvider and mcp functions set these insecure defaults.
The patch addresses these issues by removing none from the list of supported algorithms in the metadata and by changing the default behavior to disallow the plain PKCE method unless explicitly enabled. It also adds stricter checks to the authorization endpoints to reject requests that are inconsistent or insecure.
oidcProviderpackages/better-auth/src/plugins/oidc-provider/index.ts
getMetadatapackages/better-auth/src/plugins/oidc-provider/index.ts
authorizepackages/better-auth/src/plugins/oidc-provider/authorize.ts
mcppackages/better-auth/src/plugins/mcp/index.ts
getMCPProviderMetadatapackages/better-auth/src/plugins/mcp/index.ts
getMCPProtectedResourceMetadatapackages/better-auth/src/plugins/mcp/index.ts
authorizeMCPOAuthpackages/better-auth/src/plugins/mcp/authorize.ts
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| better-auth | npm | < 1.6.11 | 1.6.11 |
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"], contradicting the runtime acceptance of plain. RFC 9700 §2.1.1 (OAuth 2.1) explicitly forbids plain.
The metadata builders unconditionally inject "none" into the alg list. The runtime authorize gate is structured so a buggy client that strips the code_challenge_method parameter still enters the plain code path because the handler rewrites the missing value to "plain" before the allowlist check fires.
@better-auth/oauth-provider (the deprecation target for oidcProvider) is not affected by either defect. The metadata builder uses a JWSAlgorithms type union that structurally excludes "none". The authorize schema is code_challenge_method: z.literal("S256").optional(), which rejects plain at parse time.
Fixed in better-auth@1.6.11. The legacy oidcProvider and mcp plugins now:
"none" from id_token_signing_alg_values_supported (both plugins) and from resource_signing_alg_values_supported (mcp). Discovery no longer advertises the unsigned-token option.allowPlainCodeChallengeMethod to false. A request that explicitly passes code_challenge_method=plain is rejected with invalid_request unless the integrator opts in.code_challenge without an accompanying code_challenge_method instead of silently rewriting the missing value to plain. Clients that send code_challenge must also send code_challenge_method=S256.Discovery and runtime behavior align on S256 only by default.
Integrators who must keep plain PKCE for legacy clients can restore the previous shape with oidcProvider({ allowPlainCodeChallengeMethod: true }) (and likewise for mcp). With the opt-in set, a request that omits code_challenge_method is treated as plain again, preserving backwards compatibility while keeping the secure default for everyone else. Both legacy plugins are deprecated long-term; the recommended migration is @better-auth/oauth-provider, which never advertised none or accepted plain PKCE.
If developers cannot upgrade their applications immediately:
oidcProvider({ allowPlainCodeChallengeMethod: false }) (and the equivalent on mcp). Closes the runtime acceptance of plain even though the silent downgrade still rewrites missing methods."none" from id_token_signing_alg_values_supported. For oidcProvider, pass metadata: { id_token_signing_alg_values_supported: ["RS256"] }. For mcp, set the same on options.oidcConfig.metadata. Verify by curling the .well-known endpoint.@better-auth/oauth-provider: the package is the deprecation target and is unaffected by both defects.alg: "none") tokens.plain does not protect the authorization code if the URL leaks (Referer headers, browser history, screen capture, proxy logs). PKCE S256 is what protects against that exposure; with plain the protection is absent.Reported by @subhanUmer.
JavaScriptJavaScript