Bypass of Open Redirect Fix on lovable.dev via /..// Path Traversal in redirect parameter

How it was found

Summary:

A bypass exists for the previously patched open redirect vulnerability (report #3581815) on lovable.dev. The original fix blocked backslash-based payloads (/\ and /%5C), but fails to account for path traversal sequences combined with double slashes. By supplying /..//google.com as the redirect value, an attacker can still redirect authenticated users to arbitrary external domains.

After logging in, the application processes a redirect via: https://lovable.dev/auth/post-login?redirect=/..//google.com

The server normalizes the path traversal /../ and then treats //google.com as a protocol-relative URL, resulting in a redirect to https://google.com.

This bypass demonstrates that the previous fix used an incomplete denylist rather than a proper allowlist or URL parser validation.

Steps To Reproduce:

1. Create or log in to an existing account on lovable.dev
2. Visit the following URL while authenticated: https://lovable.dev/auth/post-login?redirect=/..//google.com
3. Observe that you are redirected to https://google.com (external domain)

Supporting Material/References:

• Previous related report: #3581815 (resolved)
• Payload used: /..//google.com
• Final redirect URL observed in browser: https://google.com
• The fix from report #3581815 only blocked /\ and /%5C variants
• This payload was not covered by the fix
• I have a poc

Impact

An attacker can craft a trusted lovable.dev URL that silently redirects authenticated users to an arbitrary external website. This can be used in targeted phishing campaigns where victims trust the lovable.dev domain in the link. Since the redirect occurs post-login, victims are already authenticated, making social engineering attacks significantly more credible. The attacker could redirect to a lookalike page to steal credentials or session tokens.