Summary
better-auth's deprecated oidc-provider plugin and the mcp plugin fail to validate the URI scheme of registered OAuth redirect_uris, allowing javascript: URLs to be stored and reused.
When a consent page blindly navigates the browser to the returned redirectURI, attacker-supplied JavaScript can execute in the authorization server's origin, exposing user sessions and enabling account takeover.
Affected context
This vulnerability affects deployments of better-auth that:
- Use the deprecated oidc-provider plugin or the mcp plugin for OAuth/OIDC flows
- Allow clients to register redirect_uris without enforcing allowed schemes (e.g., https)
- Implement a consent page that directly navigates window.location (or similar APIs) to the redirectURI returned by the authorization server
The issue is most relevant where browser-based consent UIs trust the authorization server's response and do not perform additional client-side validation of redirect targets.
Exploit preconditions
- Attack surface: Web-based OAuth/OIDC consent flows handled by better-auth's oidc-provider or mcp plugin.
- Required access: Ability to register or configure an OAuth client, including setting a redirect_uri entry.
- Trigger point: The victim is sent to a legitimate authorization request and reaches the consent page for the attacker-controlled client.
- Why exploitation is possible: The server does not validate the scheme of redirect_uris; a javascript: URI is accepted and returned unchanged. If the consent page assigns this value directly to window.location.href (or similar properties), the browser treats it as executable script in the authorization server's origin.
Why this happens
The underlying flaw is a lack of strict validation on redirect_uris associated with OAuth clients.
Instead of enforcing a safe set of URI schemes (such as https or well-defined custom schemes), the plugins allow arbitrary schemes, including javascript:, to be registered and later echoed back.
This behavior maps to CWE-79: Improper Neutralization of Input During Web Page Generation, because untrusted data (the redirectURI) is used in a dangerous context without neutralization or constraint, enabling execution of attacker-controlled JavaScript within the trusted origin.
Potential impact
- Theft of authorization server session tokens or cookies
- Account takeover for users authenticated to the authorization server
- Unauthorized consent grants or manipulation of OAuth approvals
- Execution of arbitrary JavaScript with the privileges of the authorization server origin
- Lateral movement into other applications relying on the same SSO or identity provider
General mitigation guidance
Effective mitigation focuses on constraining redirect targets and treating redirect_uris as untrusted input:
- Enforce strict validation of redirect_uris at registration time, allowing only https (and other explicitly trusted) schemes and disallowing javascript:, data:, and other executable schemes.
- Normalize and compare redirect_uris against a whitelist of pre-registered values rather than accepting arbitrary URIs at runtime.
- On the consent page, avoid blindly assigning server-returned URIs to window.location or similar APIs; apply scheme checks and, where possible, redirect through a controlled, server-side mechanism.
- Isolate authorization UI and session handling logic so that even if a redirect is misused, high-privilege tokens or cookies are not directly exposed to front-end scripts.
How teams detect issues like this
Detection can rely on a combination of configuration review and code analysis:
- Static analysis / code review: Search consent page implementations for patterns that assign unvalidated redirectURI values to window.location, document.location, or similar navigation APIs.
- Configuration inspection: Audit OAuth/OIDC client registrations to identify redirect_uris using non-HTTPS or unusual schemes, especially javascript: and data: URIs.
- Policy enforcement: Introduce validation hooks that enforce allowed schemes at client registration and during authorization requests, and flag violations in CI/CD pipelines.
- Automated tooling: Use security linters or application security scanners to detect open redirect and client-side navigation sinks that rely on untrusted parameters.
