June 18, 2026

Authentication Bypass via Insecure redirect_url Parameter Leading to Account Takeover

Introduction

Priyanshu parmar

3 min read

Introduction

Hey everyone, Priyanshu here. This writeup covers an authentication bypass vulnerability I found in a platform using magic link based passwordless authentication. The vulnerability was not in the magic link service itself — the JWT token validation worked correctly. The bug was in how the platform handled the redirect_url parameter after authentication, using a client-supplied UUID to determine which account to load without validating it against the authenticated token.

By simply swapping that UUID in the verification URL, I was able to take over any user account on the platform — without ever having access to the victim's inbox.

How the Authentication Flow Worked

The platform was using a third party magic link service for authentication. The signup flow worked like this:

  1. User enters their email on the signup page
  2. Platform sends a magic link to that email containing a JWT token
  3. User clicks the link — JWT is validated
  4. User is authenticated and redirected to their account via a redirect_url parameter

Step 4 is where the vulnerability lived.

Finding the Bug

While testing the signup flow with Burp Suite intercepting all traffic, I submitted my email and captured the request. Inside the response I noticed a redirect_url parameter containing what looked like a user identifier:

"redirect_url": "https://[target].io/signUp/948bcd92-7d80-444e-9c51-bdd92bab1324"

That UUID immediately caught my attention. The platform was using it to route the authenticated user to their account after the JWT was validated. My question was — is this UUID validated against the JWT on the server side, or is the server simply trusting whatever UUID gets passed in?

I decided to find out.

Exploitation

I needed two things — the victim's UUID and a valid magic link from my own email.

Step 1 — Get the victim's UUID

I signed up using the victim's email address:

victimdeadalive@gmail.com

The platform responded with a redirect_url containing the victim's UUID:

"redirect_url": "https://[target].io/signUp/948bcd92-7d80-444e-9c51-bdd92bab1324"

I noted this UUID down.

Step 2 — Generate a valid magic link with attacker's email

I signed up using my own controlled email:

attackernotdead@gmail.com

I checked my inbox and retrieved the magic link. It looked like this:

https://auth.magic.link/confirm?tlt=<ATTACKER_JWT>
&redirect_url=https://[target].io/signUp/5ca4940c-2b48-443b-b18a-e123c32afe02

The redirect_url here contained my own UUID — 5ca4940c-2b48-443b-b18a-e123c32afe02.

Step 3 — Swap the UUID

I replaced my UUID in the redirect_url with the victim's UUID:

Before:
redirect_url=https://[target].io/signUp/5ca4940c-2b48-443b-b18a-e123c32afe02
After:
redirect_url=https://[target].io/signUp/948bcd92-7d80-444e-9c51-bdd92bab1324

The full modified URL now looked like:

https://auth.magic.link/confirm?tlt=<ATTACKER_JWT>
&redirect_url=https://[target].io/signUp/948bcd92-7d80-444e-9c51-bdd92bab1324

Step 4 — Open the modified link

I opened the modified magic link in the browser.

The server validated the JWT token from my own email — valid. It then used the UUID from the redirect_url to determine which account to load — the victim's account.

Authentication bypassed. Full account access. Zero interaction from the victim.

Root Cause

The platform was performing two separate operations without cross-validating them:

JWT validation — checking that the token is properly signed and not expired ✅

Account loading — using the UUID from redirect_url to fetch and return the account ✅

But it never verified — does this UUID actually belong to the email address in the JWT? ❌

The JWT authenticated the attacker's email correctly. But the account it unlocked was determined entirely by a client-controlled parameter. Since the redirect_url is part of the URL the attacker controls — and can be freely modified — any account on the platform could be targeted.

Correct flow:
JWT email → look up user by email → load that user's account
Vulnerable flow:
JWT email → validate token ✅
redirect_url UUID → load whatever account this UUID belongs to ← no cross-check ❌

This is fundamentally an IDOR — the object (user account) was referenced via a user-supplied identifier (UUID in redirect_url) with no authorization check confirming the requester owned that account.

Impact

  • Complete account takeover of any registered user on the platform
  • No interaction required from the victim beyond having an existing account
  • Attack requires only knowing the victim's email address — obtainable via public profiles, social engineering, or email enumeration
  • Scales to every user on the platform with no rate limiting

Closing Thoughts

The bug was not in the magic link service — the JWT validation was working as intended. The vulnerability was entirely in how the platform used the redirect_url parameter after authentication completed.

Anytime you see a user identifier in a URL parameter involved in an authentication or post-authentication flow, it is worth checking whether the server validates that identifier against the authenticated session or simply trusts whatever value is passed in.

That one question — is this UUID tied to the authenticated token or just trusted blindly — led to a complete account takeover finding on a production platform.

Thanks for reading. Feel free to connect on LinkedIn and instagram .

— Priyanshu Parmar