Am I affected?
Check each condition. Users are affected when all of the first three hold.
- Their application enables the
oidc-provider plugin or the mcp plugin from better-auth/plugins. The mcp plugin wraps the same provider and carries the same defect. Both are on the migration path to @better-auth/oauth-provider, which is not affected.
- Their application
better-auth version is 1.6.12 or earlier on the stable line, or any 1.7.0-beta build on the pre-release line. Both release lines carry the same defect.
- Their application consent page is a client component that reads
redirectURI from the authClient.oauth2.consent(...) response and assigns it to a browser navigation target such as window.location.href, location.assign, or location.replace.
Two conditions raise an application's exposure:
- It sets
allowDynamicClientRegistration: true. Client registration is then unauthenticated, so any visitor can plant the malicious client. The default is false, which limits planting to authenticated users.
- It exposes the consent page to ordinary end users rather than to a restricted operator audience.
A developer's application is not affected when any of these hold:
- Their application copied the project's
consent-buttons.tsx demo verbatim. That file reads a uri field that this plugin never returns, so its navigation branch never runs and it falls through to an error toast.
- Their application completse the consent flow with a server-side redirect, for example a Next.js or Remix server action. Browsers do not follow a
javascript: URL delivered in a Location response header.
- Their application uses
@better-auth/oauth-provider instead of the deprecated oidc-provider plugin.
Fix:
- Upgrade to
better-auth@1.6.13 (stable) or 1.7.0-beta.4 (pre-release).
- If developers cannot upgrade their applications, see the workarounds below.
Summary
The deprecated oidc-provider plugin registers OAuth clients without validating the scheme of their redirect_uris. An attacker stores a javascript: URI as a client redirect target, and the authorization server later returns that URI to the browser in the consent response. A consent page that navigates to the returned value then executes attacker JavaScript in the authorization-server origin, which exposes the victim's session and enables account takeover. The mcp plugin wraps the same provider and carries the same defect, so MCP server deployments are affected as well; like oidc-provider, it is migrating to @better-auth/oauth-provider.
Details
Client registration accepts any string. The registration body schema types redirect_uris as z.array(z.string()) with no scheme check, so POST /oauth2/register stores a value such as javascript:fetch('/api/auth/get-session')//. In the default configuration, allowDynamicClientRegistration is false, so registration requires an authenticated session; any logged-in user qualifies. With dynamic client registration enabled, registration is unauthenticated.
The dangerous value then survives the authorization-code flow unchanged. GET /oauth2/authorize matches the request redirect_uri against the stored list by exact string equality, so the registered javascript: URI matches itself and is written into the consent verification record. When the user approves on the consent screen, the handler runs new URL(value.redirectURI), appends the authorization code through searchParams.set, and returns the result in JSON under the key redirectURI. The javascript: scheme passes through new URL intact, and a trailing // in the payload comments out the appended query string.
The plugin documents the consent call but not the redirect step that follows it, and it gives no warning that redirectURI can carry a dangerous scheme. The natural way an operator completes the flow is to assign res.data.redirectURI to window.location.href. Per the URL specification and browser behavior, navigating window.location to a javascript: URL executes the script body in the current document origin, which here is the authorization server. The injected script can call /api/auth/get-session and any other session-scoped endpoint in that origin.
The sibling @better-auth/oauth-provider package already prevents this. It validates the same field with SafeUrlSchema, which rejects the javascript:, data:, and vbscript: schemes and requires HTTPS or a loopback host. The deprecated plugin never received that control; the field shipped unvalidated when the registration endpoint was first added, well before the sibling package introduced SafeUrlSchema.
Patches
Fixed in better-auth@1.6.13 (stable) and 1.7.0-beta.4 (pre-release). The fix adds scheme validation to the redirect_uris of both the oidc-provider and mcp plugins, matching the control @better-auth/oauth-provider already enforces.
Workarounds
If developers cannot upgrade, apply one of the following.
- Harden the consent page. Before navigating, parse the returned value and navigate only when its scheme is
http: or https:. For example, reject the value when new URL(redirectURI).protocol is neither http: nor https:, and show an error instead of navigating. This closes the sink regardless of what the server returns.
- Migrate to
@better-auth/oauth-provider. It validates redirect URIs at registration and is the supported replacement for the deprecated plugin.
- Keep
allowDynamicClientRegistration at its default of false and restrict who can register clients. This does not remove the issue, because any authenticated user can still register a malicious client, but it removes the unauthenticated path.
Impact
This is a stored DOM cross-site scripting issue in the authorization server's own origin, which leads to account takeover. An attacker who can register a client plants a javascript: redirect URI. A victim who visits the attacker's authorize URL and approves consent runs attacker JavaScript in the authorization-server origin. From there the script reads /api/auth/get-session, calls any session-scoped endpoint, and takes over the account. The consent screen shows the attacker-controlled client name, which makes the approval click easy to socially engineer.
The realized impact depends on one operator-side precondition: the consent page must assign the returned redirectURI to a navigation target. Better Auth itself never performs that navigation, which is why the assessed Attack Complexity is High and the score sits below a pure server-side execution flaw. The deprecated status of the oidc-provider plugin does not reduce the impact. The plugin remains published, importable, and documented, and users on the affected versions cannot opt out without changing their integration. The mcp plugin wraps the same provider and is affected on the same versions; its docs announce a move to @better-auth/oauth-provider, but until users migrate or upgrade, the affected published versions stay exposed. @better-auth/oauth-provider validates redirect URIs and provides MCP support, so it is the migration target for both plugins.
Credit
Reported by @hillalee
Resources
References
hillalee Reporter
Am I affected?
Check each condition. Users are affected when all of the first three hold.
oidc-providerplugin or themcpplugin frombetter-auth/plugins. Themcpplugin wraps the same provider and carries the same defect. Both are on the migration path to@better-auth/oauth-provider, which is not affected.better-authversion is1.6.12or earlier on the stable line, or any1.7.0-betabuild on the pre-release line. Both release lines carry the same defect.redirectURIfrom theauthClient.oauth2.consent(...)response and assigns it to a browser navigation target such aswindow.location.href,location.assign, orlocation.replace.Two conditions raise an application's exposure:
allowDynamicClientRegistration: true. Client registration is then unauthenticated, so any visitor can plant the malicious client. The default isfalse, which limits planting to authenticated users.A developer's application is not affected when any of these hold:
consent-buttons.tsxdemo verbatim. That file reads aurifield that this plugin never returns, so its navigation branch never runs and it falls through to an error toast.javascript:URL delivered in aLocationresponse header.@better-auth/oauth-providerinstead of the deprecatedoidc-providerplugin.Fix:
better-auth@1.6.13(stable) or1.7.0-beta.4(pre-release).Summary
The deprecated
oidc-providerplugin registers OAuth clients without validating the scheme of theirredirect_uris. An attacker stores ajavascript:URI as a client redirect target, and the authorization server later returns that URI to the browser in the consent response. A consent page that navigates to the returned value then executes attacker JavaScript in the authorization-server origin, which exposes the victim's session and enables account takeover. Themcpplugin wraps the same provider and carries the same defect, so MCP server deployments are affected as well; likeoidc-provider, it is migrating to@better-auth/oauth-provider.Details
Client registration accepts any string. The registration body schema types
redirect_urisasz.array(z.string())with no scheme check, soPOST /oauth2/registerstores a value such asjavascript:fetch('/api/auth/get-session')//. In the default configuration,allowDynamicClientRegistrationisfalse, so registration requires an authenticated session; any logged-in user qualifies. With dynamic client registration enabled, registration is unauthenticated.The dangerous value then survives the authorization-code flow unchanged.
GET /oauth2/authorizematches the requestredirect_uriagainst the stored list by exact string equality, so the registeredjavascript:URI matches itself and is written into the consent verification record. When the user approves on the consent screen, the handler runsnew URL(value.redirectURI), appends the authorization code throughsearchParams.set, and returns the result in JSON under the keyredirectURI. Thejavascript:scheme passes throughnew URLintact, and a trailing//in the payload comments out the appended query string.The plugin documents the consent call but not the redirect step that follows it, and it gives no warning that
redirectURIcan carry a dangerous scheme. The natural way an operator completes the flow is to assignres.data.redirectURItowindow.location.href. Per the URL specification and browser behavior, navigatingwindow.locationto ajavascript:URL executes the script body in the current document origin, which here is the authorization server. The injected script can call/api/auth/get-sessionand any other session-scoped endpoint in that origin.The sibling
@better-auth/oauth-providerpackage already prevents this. It validates the same field withSafeUrlSchema, which rejects thejavascript:,data:, andvbscript:schemes and requires HTTPS or a loopback host. The deprecated plugin never received that control; the field shipped unvalidated when the registration endpoint was first added, well before the sibling package introducedSafeUrlSchema.Patches
Fixed in
better-auth@1.6.13(stable) and1.7.0-beta.4(pre-release). The fix adds scheme validation to theredirect_urisof both theoidc-providerandmcpplugins, matching the control@better-auth/oauth-provideralready enforces.Workarounds
If developers cannot upgrade, apply one of the following.
http:orhttps:. For example, reject the value whennew URL(redirectURI).protocolis neitherhttp:norhttps:, and show an error instead of navigating. This closes the sink regardless of what the server returns.@better-auth/oauth-provider. It validates redirect URIs at registration and is the supported replacement for the deprecated plugin.allowDynamicClientRegistrationat its default offalseand restrict who can register clients. This does not remove the issue, because any authenticated user can still register a malicious client, but it removes the unauthenticated path.Impact
This is a stored DOM cross-site scripting issue in the authorization server's own origin, which leads to account takeover. An attacker who can register a client plants a
javascript:redirect URI. A victim who visits the attacker's authorize URL and approves consent runs attacker JavaScript in the authorization-server origin. From there the script reads/api/auth/get-session, calls any session-scoped endpoint, and takes over the account. The consent screen shows the attacker-controlled client name, which makes the approval click easy to socially engineer.The realized impact depends on one operator-side precondition: the consent page must assign the returned
redirectURIto a navigation target. Better Auth itself never performs that navigation, which is why the assessed Attack Complexity is High and the score sits below a pure server-side execution flaw. The deprecated status of theoidc-providerplugin does not reduce the impact. The plugin remains published, importable, and documented, and users on the affected versions cannot opt out without changing their integration. Themcpplugin wraps the same provider and is affected on the same versions; its docs announce a move to@better-auth/oauth-provider, but until users migrate or upgrade, the affected published versions stay exposed.@better-auth/oauth-providervalidates redirect URIs and provides MCP support, so it is the migration target for both plugins.Credit
Reported by @hillalee
Resources
window.locationto ajavascript:URL executes the script body. https://developer.mozilla.org/en-US/docs/Web/URI/Reference/Schemes/javascriptReferences