CVE-2026-107369 in nextjs-auth0
Summary
by MITRE • 10/13/2026
The auth0/nextjs-auth0 SDK validates that the returnTo parameter is a same-origin URL. The SDK then stores this value and, in a later step, reconstructs it for the post-authentication redirect. The reconstruction logic can produce a URL that browsers interpret as an absolute or scheme-relative path, leading to a redirect to an unintended domain.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified within the auth0/nextjs-auth0 SDK stems from a flaw in how return URLs are validated and subsequently reconstructed during the authentication flow. The core issue lies in the discrepancy between the initial validation logic and the final URL construction mechanism used for post-authentication redirections. While the SDK correctly implements an initial check to ensure that the returnTo parameter provided by the client is a same-origin URL, this safeguard is effectively bypassed due to how the value is processed later in the pipeline. The system stores the validated string but fails to account for specific formatting nuances or encoding artifacts when reconstructing the redirect target, allowing attackers to manipulate the final destination despite passing the initial origin check.
From a technical perspective, the flaw exploits browser parsing behaviors regarding URL schemes and relative paths. When the SDK reconstructs the returnTo value, it does not strictly enforce absolute path constraints in all contexts. This oversight allows an attacker to supply a specially crafted string that appears valid during validation but is interpreted by web browsers as either an absolute URL pointing to a different domain or a scheme-relative path such as //evil.com/path. Because modern browsers treat double-slash prefixes differently than single slashes, the application inadvertently redirects users away from the intended origin to a maliciously controlled external site without triggering standard same-origin policy protections that would otherwise block cross-domain navigation initiated by user interaction if not for this specific parsing quirk.
The operational impact of this vulnerability is significant as it facilitates an Open Redirect attack vector within the authentication workflow. By leveraging this flaw, threat actors can craft phishing campaigns where victims are directed to look-alike login pages hosted on attacker-controlled domains after completing legitimate authentication steps with Auth0. This undermines user trust and exposes sensitive session tokens or personal information to interception by malicious entities posing as the original service provider. Furthermore, such redirects can be used in conjunction with other attack vectors like cross-site scripting or credential harvesting services, amplifying the potential damage beyond simple redirection into full account compromise scenarios for end-users who may not notice the subtle change in domain during the redirect chain.
Mitigation strategies must focus on hardening both validation and reconstruction processes to eliminate ambiguity in URL parsing. Developers should implement strict canonicalization of all return URLs before storage or use, ensuring that only absolute paths starting with a single forward slash are accepted for same-origin redirects. It is critical to avoid relying solely on client-side checks or simple string matching; instead, server-side verification using robust URL parsing libraries that explicitly reject scheme-relative formats and external domains should be enforced. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting navigation targets, although this does not replace the need for fixing the underlying application logic flaw in the SDK integration or configuration.