better-auth — 13+ OAuth/OIDC/SSO/SCIM advisories including a critical MCP-plugin refresh-token bypass (CVE-2026-53512)

View raw markdownEdit on GitHub ↗

TL;DR

better-auth — a widely-adopted TypeScript auth library commonly paired with Next.js and Supabase-style "vibe coded" stacks as an alternative to NextAuth.js/Auth.js — published 13 security advisories on 2026-06-02 (2 critical, 9 high, 1 medium, 1 low) and 4 more on 2026-06-26, spanning account takeover via SSO/SAML/OIDC, SCIM provider-ID collisions, magic-link/OTP pre-account hijacking, cross-organization billing tampering, and OAuth refresh-token flaws. The most severe for AI-tool users: CVE-2026-53512 (CVSS 9.1, critical) — the deprecated oidcProvider and mcp plugins issue OAuth refresh tokens without verifying the client's secret, so anyone who obtains a valid refresh token (via log capture, DB read, or XSS) can mint fresh access tokens indefinitely. Update to better-auth ≥ 1.6.11 (≥ 1.6.22 for the SCIM plugin); the mcp and oidcProvider plugins are deprecated and slated for removal in 1.7 — better-auth's own guidance is to migrate off them rather than keep patching.

What happened

better-auth positions itself as a framework-agnostic, TypeScript-first alternative to NextAuth.js/Auth.js, and ships a plugin architecture covering SSO, SAML, OIDC, SCIM provisioning, Stripe billing, and — relevant to AI coding agents — an MCP (Model Context Protocol) OAuth-provider plugin for authenticating MCP clients. It runs a formal internal security-review process (triage → code review → scanning → patch review → advisory), which is how this batch surfaced.

2026-06-02 batch (13 advisories, 2 critical + 9 high): covers issues across @better-auth/sso, @better-auth/oauth-provider, and the deprecated oidcProvider/mcp plugins. The standout for this repo's audience:

  • CVE-2026-53512 (critical, CVSS 9.1) — the deprecated oidcProvider and mcp plugins each expose an OAuth 2.0 token endpoint whose refresh_token grant authenticates purely on possession of the bound refresh-token database row plus a matching (public, non-secret) client_id — the plugin never verifies the confidential client's client_secret on the refresh path. Anyone who obtains a valid refresh token — via a database read, a log line, browser-side XSS, or (specific to the mcp plugin) a CORS-amplified script — can mint fresh access tokens and rotated refresh tokens indefinitely, until the token chain is explicitly revoked. This directly affects any app that stood up better-auth's MCP OAuth provider to authenticate MCP clients. Fixed in 1.6.11.
  • GHSA-p2fr-6hmx-4528 (moderate) — @better-auth/oauth-provider access tokens aren't audience-bound to the authorization grant (RFC 8707), letting a token issued for one resource be replayed against another.
  • GHSA-392p-2q2v-4372 / GHSA-7w99-5wm4-3g79 (high) — OAuth refresh-token rotation race conditions that fork the token family or allow concurrent redemption, undermining rotation-based revocation.
  • GHSA-86j7-9j95-vpqj (moderate) — stored XSS in the deprecated oidc-provider's auth-server origin via a javascript: redirect URI.

2026-06-26 batch (4 more advisories): extends the same theme —

  • GHSA-rjg6-39jm-rgg4 (critical, CVSS 9.9) — @better-auth/scim used the same logical provider ID for SCIM configuration and account ownership, letting an authenticated user mint a SCIM token that matches an existing SSO/SAML/OIDC/social provider ID and act through a provider namespace they don't own; also missing SCIM-active deactivation modeling and email-uniqueness checks on update. Fixed in 1.6.22 / 1.7.0-beta.10.
  • GHSA-qq9h-g4jm-xgf3 (high) — account takeover via pre-account hijacking on magic-link and email-OTP sign-in.
  • GHSA-prpr-5gj3-qqhg (high) — account takeover via multiple SSO flaws.
  • GHSA-h3rm-78g3-j7cp (high) — @better-auth/stripe cross-organization billing tampering in organization-subscription actions.

Vendor guidance: better-auth's own June 2026 security-update post recommends updating to the latest 1.6.x release (1.6.14 at time of posting) for both the core package and any scoped plugin packages in use, and explicitly recommends migrating off the deprecated oidcProvider and mcp plugins to @better-auth/oauth-provider rather than continuing to rely on patches to legacy code slated for removal in 1.7.

Am I affected?

# Check installed version
npm ls better-auth 2>/dev/null
cat package.json | grep -A2 '"better-auth"'

# Check whether you use the deprecated MCP or OIDC provider plugins
grep -rE "oidcProvider|mcp\(\)|@better-auth/(sso|scim|stripe|oauth-provider)" src/ 2>/dev/null

You are affected if you run better-auth < 1.6.11 (core OAuth/OIDC issues), @better-auth/scim < 1.6.22 (SCIM collision), or use the deprecated oidcProvider/mcp plugins at all — those are being removed in 1.7 and should be migrated off regardless of patch status.

IOCs

Type Value
Critical CVE CVE-2026-53512 — MCP/OIDC refresh-token client-secret bypass, CVSS 9.1
Critical GHSA GHSA-rjg6-39jm-rgg4 — SCIM provider-ID collision, CVSS 9.9
Affected better-auth < 1.6.11 (core); @better-auth/scim < 1.6.22
Fixed better-auth ≥ 1.6.11; @better-auth/scim ≥ 1.6.22
Deprecated, migrate off oidcProvider and mcp plugins (removed in 1.7)
Total advisories 13 (2026-06-02) + 4 (2026-06-26)

Update — 2026-07-18: two more @better-auth/sso CVEs, published the same day, fixed in the same 1.6.11 you should already be on

Two additional CVEs in @better-auth/sso were published on 2026-07-15 — both patched in the same 1.6.11 release already recommended above, so anyone who updated in response to CVE-2026-53512 is already fixed, but anyone still on an older build has more exposure than previously documented here:

  • CVE-2026-53513 (GHSA-5rr4-8452-hf4v, CVSS 9.6, critical) — the POST /sso/register endpoint accepts attacker-controlled oidcConfig.userInfoEndpoint, tokenEndpoint, and jwksEndpoint URLs when skipDiscovery: true is set, persists them on the ssoProvider row with no origin validation, then issues server-side fetches to those URLs during the OIDC callback and reflects the response body back through the user profile — a non-blind SSRF reachable by any authenticated session. This reaches internal-only endpoints: cloud metadata services (AWS IMDS), Redis, admin panels bound to localhost. Worse, if trustEmailVerified: true is configured (a common convenience setting), a crafted userInfo response with emailVerified: true and an attacker-chosen email triggers OAuth auto-linking against any pre-existing account with that email — turning the SSRF into full account takeover. Mitigate immediately by setting sso({ providersLimit: 0 }) to block self-registration, gating /sso/register at your reverse proxy, and setting trustEmailVerified: false.
  • CVE-2026-53515 (GHSA-gv74-j8m3-fg5f, CVSS 7.1, high) — from 1.2.10 until 1.6.11, registerSSOProvider checked only for organization-membership when handling POST /sso/register, not an owner/admin role — any organization member could attach an attacker-controlled OIDC/SAML provider to the organization, which then drives /sso/callback/{providerId} provisioning for that org.

Both are fixed in better-auth ≥ 1.6.11, same as CVE-2026-53512. If you already updated for the June batch, you're covered; if not, these two raise the urgency — CVE-2026-53513 in particular is a higher CVSS than the original headline CVE.

Update — 2026-07-23: two more CVE numbers assigned to items already in this batch

Two items from the original 2026-06-02 disclosure that were previously tracked here only by GHSA ID have now had CVE numbers assigned — no new vulnerability, just canonical IDs for context already covered above:

  • CVE-2026-45337 (GHSA-cq3f-vc6p-68fh, high) — the deviceAuthorization plugin's device-flow endpoints treated any authenticated session as the owner of a pending device code: GET /device never claimed the row, and POST /device/approve / POST /device/deny silently accepted any caller when the row's userId was unset. An authenticated attacker who learned a valid user_code before the legitimate user finished approving could bind the polling device to their own account (account takeover) or deny the legitimate sign-in. Fixed in 1.6.11 — GET /device now claims the row for the calling session, and approve/deny require strict owner equality.
  • CVE-2026-53516 (GHSA-g38m-r43w-p2q7, this repo's ID for the pre-account-hijacking item referenced above) — the OAuth callback's auto-link gate in handleOAuthUserInfo implicitly links an incoming OAuth identity to an existing local account whenever the provider asserts email_verified: true, without also checking that the local account's own emailVerified flag is true. An attacker who pre-registers an unverified account at the victim's email address, then waits for the victim to sign in via Google/GitHub/SSO, gets their OAuth identity silently attached to the attacker-controlled row — full persistent account takeover, and requireEmailVerification: true does not mitigate it. Fixed in 1.6.11: implicit linking now refuses to attach an OAuth identity to a local account with emailVerified: false.

No new update action required beyond what's already recommended below — both are covered by the same better-auth ≥ 1.6.11 upgrade.

Update — 2026-08-18: two more previously-untracked better-auth CVEs found via a direct page-walk of the vendor's own advisory list, one from the same MCP/OIDC plugins already flagged as this advisory's headline risk

Two more better-auth advisories, missed by prior sweeps' search-query rotation, surfaced this run via a direct walk of better-auth's own GitHub Security Advisories list (the same discipline this repo now applies to Cursor and Claude Code):

  • GHSA-9h47-pqcx-hjr4 (CVSS 8.7, high, published 2026-05-31). The same deprecated oidcProvider and mcp plugins already flagged above for CVE-2026-53512 ship insecure cryptographic defaults: the OIDC discovery document advertises "none" as an acceptable token-signing algorithm, and the plugins accept PKCE in plain (unhashed) form by default despite metadata claiming otherwise — a violation of OAuth 2.1 / RFC 9700. A relying party that reads the discovery document without independently pinning an algorithm may accept unsigned tokens outright; an authorization code sent as plain-text PKCE is vulnerable to interception if the URL leaks through browser history, proxy logs, or a Referer header. Note on ID discrepancy: at least one third-party aggregator (TheHackerWire) reports this issue under the label "CVE-2026-67336, published August 1, 2026" — but GitHub's own advisory page for GHSA-9h47-pqcx-hjr4 lists no CVE number and a May 31, 2026 publish date. Per this repo's accuracy bar, the GHSA record is treated as authoritative; the CVE label and August date are noted here only as reported by the secondary source, not confirmed. Fixed in the same 1.6.11 release as CVE-2026-53512 — if you already upgraded for that CVE, you're covered for this one too, but the migrate-off-deprecated-plugins guidance below applies doubly now that this plugin pair has two independent critical/high-severity findings.
  • CVE-2026-45364 (GHSA-p6v2-xcpg-h6xw, CVSS 7.3, high, published 2026-05-11, predates the June batch above). The core rate limiter keyed requests by the caller's literal textual IP address with no normalization, so an attacker with an IPv6 allocation could bypass rate limiting on authentication endpoints (sign-in, sign-up, password-reset) by rotating through addresses within their own /64 (or larger) prefix — each textually-distinct address gets its own fresh rate-limit bucket even though it's the same attacker on the same network block. This turns better-auth's brute-force protection into a per-address limit rather than a per-attacker limit for any deployment reachable over IPv6. Fixed in 1.4.17 and 1.5.0-beta.9 — note this is an older fix line than the 1.6.11 releases covering every other CVE in this advisory; confirm you're past both fix points, not just 1.6.11.

Am I affected (update): if you're already on better-auth ≥ 1.6.11 you're covered for GHSA-9h47-pqcx-hjr4; separately confirm you're past 1.4.17/1.5.0-beta.9 for CVE-2026-45364 (any 1.6.x release supersedes both). If you deploy behind IPv6-reachable infrastructure, audit your rate-limit configuration for IP-prefix-aware bucketing rather than trusting exact-address keying.

Update — 2026-08-19: two more @better-auth/scim and @better-auth/sso advisories, published 2026-07-07 and 2026-08-11

Two more better-auth advisories not previously tracked here, found this sweep — one a third distinct @better-auth/scim bug (beyond the provider-ID collision already covered above), one a fourth distinct @better-auth/sso bug (beyond the two July SSO CVEs already covered above):

  • GHSA-j8v8-g9cx-5qf4 (CVSS 8.3, high, published 2026-07-07). @better-auth/scim doesn't bind non-organization SCIM providers to the user who created them in the default configuration. Any authenticated user could read another user's non-org SCIM provider's metadata, list its connections, delete it, or — worse — regenerate its bearer token, which rotates the credential and silently revokes the legitimate owner's access while handing the attacker a valid replacement token. Fixed in 1.7.0-beta.4. No CVE assigned as of this writing.
  • GHSA-8c5h-wx78-2cfg (CVSS 8.1, high, published 2026-08-11). @better-auth/sso has two chainable domain-verification flaws: (1) when domain verification is disabled, the plugin still accepts an unverified provider domain for automatic organization assignment, letting an authenticated attacker add themselves to organizations they don't control; (2) a TOCTOU race condition lets a concurrent SSO-provider update apply a completed DNS domain-ownership proof to a different domain than the one actually tested — an attacker can "verify" a domain they don't own by racing an update against someone else's legitimate verification. Fixed in 1.4.8 / 1.6.27 / 1.7.0-rc.5. No CVE assigned as of this writing.

Both were verified directly against better-auth's own GitHub Security Advisories page (the same page-walk discipline already applied elsewhere in this advisory). Neither has independent aggregator coverage found this sweep, so — consistent with this repo's single-source standard — treat these two specific findings as unconfirmed pending a second source, even though the parent advisory as a whole remains patched based on the CVE-bearing findings already covered above. If you run @better-auth/scim or @better-auth/sso at all, update past the fixed versions above regardless.

Update — 2026-09-30: two more High advisories on the vendor tab (2026-09-28 and 09-29): a personal SSO provider can sign in as another provider's users (@better-auth/sso < 1.7.3, CVSS 8.1), and the device-authorization approval screen never showed which client was asking (better-auth 1.3.8-beta.3 – 1.6.x, CVSS 8.1, fixed 1.7.0-rc.3)

GHSA-mx9r-x6ww-qjw9 (published 2026-09-29, High 8.1, credit manus-use) — in @better-auth/sso ≥ 1.7.0-rc.2 < 1.7.0 and ≥ 1.7.0 < 1.7.3, linked accounts were matched "by issuer and account identifier alone, without verifying the provider ID performing the sign-in attempt." Anyone with a Better Auth account could register a personal SSO provider that impersonates a legitimate identity provider, then authenticate through it with a victim's account identifier and receive the victim's session — no victim interaction. Fixed 1.7.3. Until then: block SSO sign-in at the application layer, set providersLimit to 0 (stops new registrations, does not remove existing ones), audit and delete untrusted personal providers; a configured resolveUser that requires an exact provider match blocks the path. Fourth SSO-plugin account-takeover in this file's history, and the second in which the fix is "check which provider is speaking."

GHSA-q84f-53jg-9ppm (published 2026-09-28, High 8.1, credits XlabAITeam, liangjs) — the device-authorization plugin (sign in on one device by approving a code on another) did not tell the approving user "which client asked for access and which permissions it wants," so an attacker who started a device flow and got a signed-in user to approve the code received a valid session token and could "read or change any data the user's account can access." Affects better-auth 1.3.8-beta.3 through every 1.6.x; fixed 1.7.0-rc.3. Preconditions: device flow enabled, an attacker-initiated request, an active user approval. Workarounds: disable the plugin or restrict /device/code, a strict validateClient allowlist (insufficient alone), and a custom approval endpoint that loads the pending request server-side and shows client and scopes before allowing approval. This is the device-flow sibling of the owner-binding bug (CVE-2026-45337) already in this batch.

Registry check 2026-09-30: better-auth 1.7.6 (2026-09-24) is the latest npm release; NVD has no CVE for either advisory yet (keyword query, 09-20 → 09-30: zero results).

GHSA-965c-763c-88jm — Critical, CVSS 3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), published 2026-09-30, credits rick-v12 and bazumo. Better Auth "accepts OAuth sign-in state values as Magic Link tokens. An attacker knowing a user's email can leverage an OAuth state to complete a Magic Link sign-in without mailbox access or OAuth provider verification," yielding account takeover or the creation of falsely email-verified accounts. Affected better-auth ≥ 1.4.0-beta.18 < 1.7.7, fixed 1.7.7 (npm 2026-09-30). Workarounds until then: account.storeStateStrategy: "cookie", Magic Link storeToken: "hashed" with verification.storeIdentifier: "plain", or disable Magic Link or OAuth sign-in; and the advisory says to upgrade all servers together and invalidate pre-upgrade tokens and state values. For this audience it is the worst shape an auth library can have: the two most common sign-in methods an AI scaffold enables — "sign in with Google" and "email me a link" — share a token namespace, and either one on its own is fine.

GHSA-r4xp-prcw-77qf — High 7.4, 2026-09-30, credits iabdullah215 and martinfrancois. The OAuth Proxy plugin (the helper for preview deployments with changing callback URLs) "under certain configuration conditions" accepts an attacker-crafted fake user profile as legitimate, "enabling unauthorized account access without requiring provider sign-in or victim interaction." Affected ≥ 1.5.0-beta.12 < 1.7.7 → 1.7.7. Workarounds: a distinct strong OAuth Proxy secret separate from the global Better Auth secret, account.storeStateStrategy: "database", remove the plugin if unused, account.accountLinking.disableImplicitLinking: true (partial).

Also on the tab: GHSA-44jh-23m7-hpcf (Low, 2026-09-30) — @better-auth/drizzle-adapter rate limits can be exceeded by concurrent requests on PostgreSQL. With the two Highs from the 09-30 update that is five advisories in three days, all without CVEs. Upgrade better-auth to ≥ 1.7.7 and @better-auth/sso to ≥ 1.7.3, then rotate: the 9.1 does not require the attacker to have done anything detectable beforehand, so if Magic Link and OAuth were both enabled on < 1.7.7, treat every account as possibly signed into and revoke sessions.

If you are affected

  1. Update better-auth and every scoped plugin package you use to the versions above.
  2. If you use the mcp or oidcProvider plugins to authenticate MCP clients, migrate to @better-auth/oauth-provider — these plugins are deprecated and won't receive further security attention beyond 1.7 removal.
  3. Revoke and rotate all outstanding refresh tokens issued by an affected instance if you were on a pre-1.6.11 build and can't rule out token exposure (logs, DB access, XSS reports).
  4. Audit SCIM-provisioned accounts for provider-ID collisions if you run @better-auth/scim pre-1.6.22 — look for SCIM-provisioned users that unexpectedly share identifiers with SSO/SAML/OIDC/social-login accounts.
  5. See playbooks/rotating-cloud-credentials.md.

Prevention

  • Treat auth-library plugin architectures the same as any other dependency surface — audit which plugins you actually use, and remove ones you don't (each additional plugin, especially a deprecated one, is additional attack surface with a shrinking patch commitment).
  • When wiring MCP OAuth into any auth library, verify the token endpoint enforces client_secret (or PKCE for public clients) on every grant type, not just the initial authorization — refresh-token grants are a common place for this check to be silently dropped.
  • → prevention/credential-hygiene.md

The GitHub CNA published CVE-2026-114607 on 2026-10-22 for GHSA-965c-763c-88jm (the 10-04 update above), with the vendor's score and vector unchanged (CVSS 3.1 9.1, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), affected better-auth 1.4.0-beta.18 before 1.7.7, fixed 1.7.7, and the same pull request, commit and release references; the database reviewed it on 2026-10-27 and it appeared on the reviewed-critical npm listing that day. The CNA description adds the configuration conditions in one sentence: Magic Link with storeToken plain, or hashed with the global verification.storeIdentifier also hashed, a built-in social or Generic OAuth provider, and account.storeStateStrategy set to database. npm better-auth is 1.7.14 as of 2026-10-28 (its time.modified is 2026-10-27). Nothing changes for a reader who already upgraded; a scanner keyed on CVEs now flags the pre-1.7.7 range it did not before.

Sources