How I Discovered an Email Verification Bypass: A Step-by-Step Breakdown

3 min readOct 8, 2024

I easily bypassed the email verification process.

Introduction 🧐

As the internet grows, so do the risks associated with weak authentication and verification mechanisms. In my latest bug bounty submission, I discovered a significant email verification bypass vulnerability that allowed me to take control of an account by simply altering the verification link. This vulnerability not only bypassed the email verification process but also allowed an attacker to create accounts using any email address without the victim’s consent. Here’s how I found it and how you can avoid this in your applications.

The Discovery 🔎

Context:

During a routine test of a web application’s sign-up process, I received a typical email verification link after registering a new account. Here’s what the verification link looked like:

https://app.example.me/signup/activation?token=c6dc625e-5b5a-4627-b39c-98e0dfcbc22f&source=trial&email=attacker@gmail.com&chkNR=false

This link contained the following key parameters:

Token: A unique string used to validate the email and verify account ownership.
Email: The email address of the user.
Other Parameters: Miscellaneous parameters (e.g., source and chkNR).

At first glance, this seemed like a typical verification flow, but something interesting caught my eye — the email parameter was included in the URL. What if I could change the email to another address? 😗

Step-by-Step Breakdown 👣

Let me walk you through the process that led to this discovery.

Step 1: Modifying the Email Parameter

I modified the email parameter from attacker@gmail.com to a different email address (for this example, I used victim@gmail.com):

https://app.example.me/signup/activation?token=c6dc625e-5b5a-4627-b39c-98e0dfcbc22f&source=trial&email=victim@gmail.com&chkNR=false

When I pasted the modified URL into the browser, the page loaded with the victim’s email address in the URL. Now I entered first/last name and a password.

Step 2: Intercepting the Request

Using Burp Suite, I intercepted the request when submitting the form to see if there were any vulnerabilities in how the data was being handled. The intercepted request looked something like this:

{
  "firstName": "Attacker",
  "lastName": "Smith",
  "email": "victim@gmail.com",
  "password": "strongpassword123",
  "token": "c6dc625e-5b5a-4627-b39c-98e0dfcbc22f"
}

The key parameter here was the token, which tied the request to the email verification process.

Step 3: Removing the Token 😈

Here’s where things got interesting. I removed the token field from the JSON body entirely and forwarded the modified request to the server:

{
  "firstName": "Attacker",
  "lastName": "Smith",
  "email": "victim@gmail.com",
  "password": "strongpassword123"
}

To my surprise, the account was successfully created under the victim’s email address without any email verification! The server failed to validate the token and simply proceeded with the account creation process.

The Impact

This vulnerability is quite severe because it allows an attacker to:

Create accounts using any email address, which can be used for impersonation or account hijacking.
Gain control of accounts without the user’s consent or knowledge.
Potentially use this attack for phishing or fraud, as it exploits trust in the verification process.