CVE-2026-53512 is an authentication flaw (CWE-287) in Better Auth before 1.6.11. The legacy oidcProvider and mcp plugins accept a refresh_token grant without checking the confidential client's secret. It is scored 9.1 critical. Upgrade to 1.6.11, or move to the oauth-provider package.
What's affected
Better Auth, the TypeScript authentication library, before version 1.6.11. The fixed version is 1.6.11.
Only the legacy oidcProvider and mcp plugins are affected. The advisory says the @better-auth/oauth-provider package is not affected, and the legacy plugins are deprecated in favor of it.
The token endpoints involved are /api/auth/oauth2/token and /api/auth/mcp/token.
The flaw needs a valid refresh token bound to a client, so the main risk is a leaked or stolen token being used without the confidential client's secret.
How to check if you're exposed
See which version you have:
npm ls better-auth
pnpm why better-auth
Then search your code for the two plugins:
grep -rnE "oidcProvider|mcp\(" src/ --include=*.ts
If neither plugin is in your auth setup, this CVE does not apply to your running code. If either is, and your version is below 1.6.11, you are affected.
You can also run the free in-browser dependency scan or browse the Gold directory to see where this component shows up in your stack.
What to do now
- Find applications that depend on
better-authand read their resolved version. - Upgrade to 1.6.11 or later and redeploy.
- Plan a move from the legacy
oidcProviderandmcpplugins to@better-auth/oauth-provider, as the maintainers recommend. - Rotate client secrets and refresh tokens for confidential clients if you suspect token exposure.
- After the upgrade, test the token endpoint: a refresh request from a confidential client without its secret should now be refused.
- Review any logs of token requests to the two endpoints for unusual clients.
Why it matters
OAuth distinguishes public clients, such as mobile apps that cannot keep a secret, from confidential clients, such as a server that can. For a confidential client, every grant at the token endpoint should prove the client's identity. The advisory says the refresh_token grant checked only that the caller held the bound refresh token and a matching client_id, so a secret was never asked for.
The code change shows the intent: refresh grants now require the registered client_secret from confidential clients, as the authorization code path already did. Public clients still skip secret validation. Secret comparisons now use constant time equality, and the /mcp/token endpoint no longer sends a wildcard CORS header.
The record lists several weakness types, including CWE-287, improper authentication, and CWE-306, missing authentication for a critical function. It does not report exploitation, and the CVE is not in the CISA KEV catalog. The threat is token theft: anyone who obtains a refresh token can mint new access tokens with no second factor in the form of the secret.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is the new oauth-provider package affected?
The advisory says no. It recommends it as the replacement for the legacy plugins.
I use neither plugin. Do I need to act?
No emergency, but upgrade at your next release. Being able to prove the plugins are unused is the useful result of the check.
Sources
Last reviewed: 19 October 2026.
