GHSA-86J7-9J95-VPQJ: Stored Cross-Site Scripting in Better Auth Plugins via Malicious Redirect URIs

Better Auth is a comprehensive authentication framework designed for Node.js environments. The software provides modular extension points via plugins, including the deprecated oidc-provider and mcp plugins. These plugins expose endpoints designed for dynamic or configuration-based registration of client applications.\n\nThe dynamic client registration process requires client applicants to supply redirect URIs. These URIs are cached on the server database. When a victim user initiates an authentication flow against the registered client, the authentication server redirects the user's browser session to one of the authorized URIs.\n\nPrior to the patch, the system failed to enforce protocol constraints on redirect URIs during registration. This design omission allows a malicious actor to inject URIs containing active code-execution pseudo-protocols. The resultant vulnerability constitutes Stored Cross-Site Scripting (Stored XSS) within the authentication server's web origin.

The root cause of this vulnerability lies in the input validation schema defined for the registration endpoints. Both the oidc-provider and mcp plugins leveraged Zod schemas that defined the redirect_uris parameter simply as an array of strings. The framework accepted any input value that matched this broad schema, failing to inspect the protocol scheme of the URLs.\n\nModern web browsers process several pseudo-protocols directly within the context of the active origin. When a client application redirects a browser by assigning an unsafe protocol scheme, such as javascript:, data:, or vbscript:, to window.location.href, the browser executes the payload. The code runs with the execution privileges of the hosting origin.\n\nBecause the registered redirect URIs are stored in the server's database, the execution sequence behaves as a Stored XSS payload. Every time a user initiates and completes an authorization consent flow for the attacker-controlled application, the server loads and executes the malicious URI. This occurs without requiring further manual script injection from the attacker.

An analysis of the patch shows that the vulnerability was resolved by centralizing protocol validation in the core library. Prior to version 1.6.13, the Zod schemas in oidc-provider/index.ts and mcp/index.ts only validated that the input was a string array:\n\ntypescript\n// Pre-patch schema definition\nconst registerOAuthApplicationBodySchema = z.object({\n redirect_uris: z.array(z.string())\n});\n\n\nThe fix, introduced in commit be32012ca3507a62371d1baa09cdacd5123a99bf, implements a consolidated verification utility in packages/core/src/utils/url.ts. It establishes an explicit blacklist of forbidden schemes and refines the registration schemas using this utility:\n\ntypescript\n// Safe URL check implementation\nexport const DANGEROUS_URL_SCHEMES = ['javascript:', 'data:', 'vbscript:'];\n\nexport function isSafeUrlScheme(value: string): boolean {\n if (!URL.canParse(value)) {\n return true; // Relative URIs are considered safe\n }\n return !DANGEROUS_URL_SCHEMES.includes(new URL(value).protocol);\n}\n\n\nThe validation schemas in the plugins now actively refine the input arrays. This prevents the persistence of dangerous URIs to the database during client registration:\n\ntypescript\n// Patched schema definition\nconst registerOAuthApplicationBodySchema = z.object({\n redirect_uris: z.array(\n z.string().refine(isSafeUrlScheme, {\n message: 'redirect_uri cannot use a javascript:, data:, or vbscript: scheme',\n })\n )\n});\n

Exploitation of this vulnerability requires network access to the registration endpoints of the authentication server. An attacker begins by preparing an active script payload encoded within a javascript: URI block. The payload is designed to access session states and transmit them to an external endpoint.\n\nmermaid\ngraph LR\n A["Attacker"] -- "1. Registers javascript: URI" --> B["Better Auth Server"]\n C["Victim User"] -- "2. Authorizes Application" --> B\n B -- "3. Assigns location.href" --> C\n C -- "4. Executes Script in Origin" --> D["Attacker Server"]\n\n\nThe attacker submits a registration request to /oauth2/register containing the payload in the redirect_uris field. Once the client application is successfully registered, the attacker constructs a standard authorization link targeting the application.\n\nWhen a victim user navigates to the authorization link and grants consent, the server attempts to process the redirection. The application reads the registered redirect_uri from the database and assigns it to window.location.href. The victim's browser immediately parses the javascript: prefix and executes the trailing payload in the origin context of the auth-server.

The security impact of this vulnerability is critical. Because the executed scripts run directly within the origin of the authentication server, they bypass same-origin policy boundaries. The attacker obtains full execution capabilities under the security context of the identity provider.\n\nThe executed script can read active session tokens, local storage, and session storage containing credential material. If session cookies lack the HttpOnly attribute, they are accessible to the script. The script can also make authenticated API calls on behalf of the victim to modify credentials, change security configurations, or retrieve user profiles.\n\nAdditionally, there is no assigned CVE for this advisory. Organizations relying solely on NVD or CVE databases for threat intelligence will fail to detect this vulnerability. This highlights the importance of monitoring vendor advisories and GitHub Security Advisories.

The primary remediation is upgrading the core library package. Organizations must upgrade better-auth to version v1.6.13 or v1.7.0-beta.4. These releases apply strict scheme validation and reject malicious redirect URIs at registration.\n\nBecause the oidc-provider and mcp plugins are deprecated, long-term remediation should include migration. Engineering teams should transition authentication architectures to @better-auth/oauth-provider. This package enforces stricter transport security configurations.\n\nAs a defense-in-depth measure, teams should enforce a robust Content Security Policy (CSP). The CSP should restrict the execution of inline scripts and ensure that script-src directives explicitly list trusted sources. This mitigates execution risks even if an application bypasses input validation.