Which versions of Better Auth are affected by EUVD-2026-51816?

Better Auth (versions before 1.6.11) contains a critical authentication bypass vulnerability that allows attackers to forge authentication tokens and gain unauthorized access to protected systems.. A patch is available.

How to fix or mitigate EUVD-2026-51816?

Immediately identify all systems running Better Auth before version 1.6.11, prioritizing production and internet-exposed instances. Within 7 days, upgrade all affected deployments to Better Auth 1.6.11 or later after testing in a staging environment. Within 30 days, audit authentication logs from the vulnerability disclosure date forward to identify and investigate any suspicious token activity or unauthorized access.

Better Auth EUVD-2026-51816

Q: What is the CVSS score of EUVD-2026-51816?

EUVD-2026-51816 has a CVSS 4.0 base score of 9.4 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.2%.

| CVE-2026-67336 CRITICAL

Use of a Broken or Risky Cryptographic Algorithm (CWE-327)

2026-08-01 VulnCheck

GHSA-mw34-3w2r-wp9p

Information Disclosure Better Auth

9.4

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

9.4 CRITICAL

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.7 HIGH

Network-reachable and unauthenticated (AV:N/PR:N) but success depends on relying-party mis-negotiation or URL exposure (AC:H); impact crosses to relying-party systems (S:C) with high confidentiality/integrity and no availability effect.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N

4.0 AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 01, 2026 - 13:04 vuln.today

Analysis Generated

Aug 01, 2026 - 13:04 vuln.today

Patch available

Aug 01, 2026 - 13:01 EUVD

CVE Published

Aug 01, 2026 - 12:22 cve.org

CRITICAL 9.4

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

26 npm packages depend on better-auth (19 direct, 7 indirect)

Ecosystem-wide dependent count for version 1.6.11.

DescriptionCVE.org

better-auth versions before 1.6.11 contain insecure cryptographic defaults in the oidcProvider and mcp plugins that advertise the none algorithm and accept plain PKCE by default. Attackers can exploit algorithm negotiation to accept unsigned tokens or intercept authorization codes when PKCE plain is used instead of the required S256 method.

AnalysisAI

Authentication bypass in Better Auth before 1.6.11 stems from insecure cryptographic defaults in the legacy oidcProvider and mcp plugins, which advertise the 'none' signing algorithm in OIDC discovery and accept plain PKCE by default. Relying parties whose JWT libraries negotiate the algorithm from discovery metadata without pinning can be tricked into accepting unsigned ID tokens, while exposed authorization URLs allow interception of codes because plain PKCE offers no protection. Reported by VulnCheck with a vendor patch available; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

The affected component is Better Auth, a TypeScript/JavaScript authentication framework, specifically its OpenID Connect provider surface exposed via the oidcProvider() plugin and the mcp() plugin (which delegates to oidcProvider and inherits its defaults). The root cause maps to CWE-327 (use of a broken or risky cryptographic algorithm): the metadata builders unconditionally inject 'none' into id_token_signing_alg_values_supported (and resource_signing_alg_values_supported for mcp on the OAuth protected-resource metadata), signaling to relying parties that unsigned tokens are acceptable. Separately, the authorize handler silently rewrites a missing code_challenge_method to 'plain' before the allowlist check, so plain PKCE is accepted at runtime even though discovery advertises only S256 - a contradiction that violates RFC 9700 §2.1.1 (OAuth 2.1), which forbids plain. The canonical replacement package @better-auth/oauth-provider excludes 'none' from discovery and rejects 'plain' at parse time, and is not affected. Affected CPE: cpe:2.3:a:better-auth:better-auth:*:*:*:*:*:*:*:*.

RemediationAI

Vendor-released patch: better-auth 1.6.11 - upgrade to 1.6.11 or later, which removes 'none' from the advertised algorithm list and stops accepting plain PKCE. Where feasible, migrate off the deprecated oidcProvider and mcp plugins to the canonical @better-auth/oauth-provider package, whose discovery document excludes 'none' and whose authorize schema rejects 'plain' at parse time. If you cannot upgrade immediately, apply the workarounds in the GHSA advisory (https://github.com/better-auth/better-auth/security/advisories/GHSA-9h47-pqcx-hjr4): concretely, ensure relying parties pin a specific signing algorithm (e.g. RS256) rather than negotiating from the discovery document so unsigned 'none' tokens are refused, and enforce S256-only PKCE by rejecting requests with code_challenge_method=plain or a missing method rather than downgrading to plain - the trade-off being that legacy clients that omit or send plain PKCE will break and must be updated. Also treat authorization URLs as sensitive and avoid logging or exposing them beyond the user agent and OP to blunt code interception.