Better Auth CVE-2026-67336

Exploitation requires the target application to run better-auth below 1.6.11 with the legacy oidcProvider() or mcp() plugin enabled. For the unsigned-token path, a relying party of that OIDC server must use a JWT verification library that performs algorithm negotiation from the discovery document without pinning to a specific signing algorithm - if the RP pins its algorithm, the 'none' advertisement is inert. For the PKCE path, the authorization URL must be exposed to some party other than the user agent and the OP, and the client must use or omit code_challenge_method (which is silently downgraded to 'plain'); if S256 is enforced end-to-end there is no exposure. Limiting factors: the flaw is not exploitable against a correctly configured relying party, requires either RP-side algorithm mis-negotiation or authorization-URL exposure (reflected in CVSS AC:H and AT:P), and applications on @better-auth/oauth-provider are not affected.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N, base 9.4) reflects a network-reachable, unauthenticated issue with high confidentiality and integrity impact on both the vulnerable system and subsequent systems (relying parties), but with elevated attack complexity (AC:H) and a present attack requirement (AT:P). Those two conditions are the key tempering signals: exploitation is not turn-key. The 'none'-algorithm path only bites relying parties whose JWT verification performs algorithm negotiation from discovery without pinning a real signing algorithm - a client-side misconfiguration outside the affected server's control - and the PKCE path requires the authorization URL to be observable by a party other than the user agent and the OP. No EPSS score was provided in the input, and the CVE is not in CISA KEV, so there is no evidence of active or widespread exploitation. There is no POC referenced. This is a genuine high-severity design flaw worth prompt remediation because the impact is authentication/token integrity, but the real-world exploitability is gated by relying-party behavior and network exposure rather than being a default-config remote takeover.

An attacker positioned to observe an application's OIDC discovery document forges an ID token signed with alg=none and presents it to a relying party whose JWT library negotiates the algorithm from that metadata without pinning, causing the relying party to accept the unsigned token and authenticate the attacker as an arbitrary user. Alternatively, where the authorization URL is exposed to a third party and plain PKCE is in use, the attacker intercepts the authorization code and completes the flow because plain PKCE provides no cryptographic binding. No public POC is referenced, and the high attack complexity (AC:H) plus present attack requirement (AT:P) mean success depends on relying-party misconfiguration or code exposure.