🛡️ CVE-2026-67336 — better-auth
Description
Better Auth has insecure cryptographic defaults in oidcProvider: alg=none advertised and plain PKCE accepted by default
Am I affected?
Users are affected if all of the following are true:
- Their application uses
better-authat a version below the patched release. - Their application enables
oidcProvider()frombetter-auth/plugins/oidc-providerormcp()frombetter-auth/plugins/mcp(the mcp plugin delegates tooidcProviderand 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"], contradicting the runtime acceptance of plain. RFC 9700 §2.1.1 (OAuth 2.1) explicitly forbids plain.
Details
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.
Patches
Fixed in [email protected]. The legacy oidcProvider and mcp plugins now:
- Drop
"none"fromid_token_signing_alg_values_supported(both plugins) and fromresource_signing_alg_values_supported(mcp). Discovery no longer advertises the unsigned-token option. - Default
allowPlainCodeChallengeMethodtofalse. A request that explicitly passescode_challenge_method=plainis rejected withinvalid_requestunless the integrator opts in. - Reject a
code_challengewithout an accompanyingcode_challenge_methodinstead of silently rewriting the missing value toplain. Clients that sendcode_challengemust also sendcode_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.
Workarounds
If developers cannot upgrade their applications immediately:
- Disable plain PKCE explicitly: set
oidcProvider({ allowPlainCodeChallengeMethod: false })(and the equivalent onmcp). Closes the runtime acceptance ofplaineven though the silent downgrade still rewrites missing methods. - Override the metadata to drop
"none"fromid_token_signing_alg_values_supported. ForoidcProvider, passmetadata: { id_token_signing_alg_values_supported: ["RS256"] }. Formcp, set the same onoptions.oidcConfig.metadata. Verify by curling the.well-knownendpoint. - Migrate to
@better-auth/oauth-provider: the package is the deprecation target and is unaffected by both defects.
Impact
- Algorithm-negotiation downgrade: relying parties that read the discovery document without pinning may accept unsigned (
alg: "none") t
How this vulnerability can be exploited
This issue can be reached over the network, attack complexity is high, an attacker needs no privileges on the target. No user interaction is required. The scope is changed, meaning a successful attack can affect components beyond the vulnerable one. Rated impact: confidentiality high, integrity high, availability none.
Weakness class
CVE-2026-67336 is classified as CWE-1188: Insecure Default Initialization of Resource. Default settings are insecure, so an installation is exposed until someone changes them.
Affected software
CVE-2026-67336 is recorded against 2 packages.
- better-auth
- unknown
Timeline and source
Published on 7 July 2026 and last revised on 2 August 2026. No public exploit is currently recorded for this entry. Record sourced from NVD.
References
Details
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
Affected Packages
| Software | From version | Fixed in |
|---|---|---|
| better-auth | — | — |
| unknown | — | — |
References
Similar Threats
- High CVE-2026-67327
- High CVE-2026-53515
- Critical CVE-2026-53513
- Critical CVE-2026-53512
- High CVE-2026-53514
More CVE 2026 advisories
Browse all of CVE 2026 in the advisory index.
Site Security Check
Is better-auth part of your stack?
CVE-2026-67336 is rated CVSS 8.7 High. BotEraser scans your installation against known CVE records and tells you whether this vulnerability applies to the versions you actually run.
Scan My Site Free →No credit card required · Results in minutes
ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.