Summary
better-auth versions before 1.1.20 contain an open redirect issue in the trustedOrigins validation logic for absolute URLs and wildcard domains.
By crafting malicious callbackURL parameters that bypass origin checks, attackers can trigger redirects that expose sensitive tokens and enable account takeover.
Affected context
This vulnerability occurs in applications using better-auth's redirect-based authentication flows, where callbackURL parameters are validated against a trustedOrigins list.
It typically manifests when absolute URLs or wildcard domains are allowed and origin matching logic does not strictly enforce exact, scheme-aware, and path-aware checks.
Environments relying on redirect URIs to deliver tokens or authorization codes via URL parameters are particularly exposed, especially when these redirects are used after login or consent.
Exploit preconditions
- Attack surface: Public-facing authentication endpoints that accept a callbackURL or similar redirect parameter.
- Required access: Ability to trick a user into following a crafted authentication link (e.g., via phishing, embedded links, or malicious web content).
- Trigger point: The point at which better-auth validates the callbackURL against trustedOrigins and issues a redirect to that URL after successful authentication.
- Why exploitation is possible: The origin validation logic for absolute URLs and wildcard domains is permissive, allowing crafted URLs to appear trusted while actually pointing to attacker-controlled domains that can capture tokens.
Why this happens
The underlying bug stems from flawed URL and origin validation logic that maps to CWE-601: Open Redirect.
Instead of strictly binding redirects to a small set of exact, pre-registered callback endpoints, the implementation relies on broad or incorrectly parsed trustedOrigins rules.
This can include improper handling of wildcard domains, partial string matching, or misinterpretation of absolute URLs, allowing attacker-supplied URLs to be treated as trusted and used in redirects.
Potential impact
- Attackers can redirect users to malicious sites that capture access tokens, session identifiers, or authorization codes.
- Compromised tokens may enable full account takeover of affected users.
- Theft of OAuth or similar credentials can lead to unauthorized access to APIs and protected resources.
- Abuse of the redirect mechanism can facilitate phishing campaigns that appear to originate from legitimate authentication flows.
General mitigation guidance
Mitigation focuses on tightening redirect and origin handling patterns rather than relying on broad trust lists.
Recommended defensive patterns include:
- Restricting callback and redirect URLs to a small, explicit allowlist of exact URLs or well-scoped paths.
- Avoiding wildcard domains or broad pattern matching for trustedOrigins wherever possible.
- Normalizing and parsing URLs with robust libraries, comparing structured components (scheme, host, port, path) rather than raw strings.
- Ensuring tokens or authorization codes are not exposed in easily exfiltrated locations, and using server-side session bindings where feasible.
- Applying least-privilege principles to tokens, including short lifetimes and audience restrictions, to limit damage if leakage occurs.
How teams detect issues like this
Detection typically centers on code-path and configuration review of redirect handling.
Useful approaches include:
- Static analysis rules or custom linters that flag dynamic redirects based on user-controlled parameters.
- Code review checklists that explicitly examine trustedOrigins, callback URL validation, and wildcard usage.
- Logging and monitoring of redirect destinations from authentication flows, with alerts for unexpected domains or patterns.
- Security tests and automated scanners that attempt to supply crafted callbackURL values to identify open redirect behavior.
