Introduction

Email verification is one of the most fundamental security mechanisms in modern web applications. It ensures that users actually own the email address they register with.

But what happens when that trust is broken?

I go by kjulius, a regular self-taught Ethical Hacker. 🪞🗿

In this write-up, I’ll walk through how I discovered and responsibly reported an email verification bypass in a real-world application, allowing account creation with unverified email addresses.

🎯 Target Overview

During routine reconnaissance, I came across the signup page of:

👉 https://subdomain.target.com/signup

The application follows a standard registration flow:

• Enter company name and email.
• Receive a verification link.
• Complete account setup.

At first glance, everything looked normal… until I tested one small feature.

🧠 The Idea

While on the verification page, I noticed an option:

“Change your e-mail”

This immediately raised a question:

What happens if I change the email after the verification link has already been sent?

That’s where things got interesting.

🔍 Step-by-Step Discovery

1. Initial Registration

I registered using my own email:

[email protected]

A verification link was sent to my inbox.

2. Changing the Email

On the next page, I clicked:

Change your e-mail

Then I replaced it with:

[email protected]

The application responded:

“A verification email has been sent to your new email address.”

3. Unexpected Behavior

Here’s where the flaw appeared:

👉 The verification email was NOT sent to the new email ([email protected])
👉 It was still sent to my original email ([email protected])

4. Verifying the Account

I clicked the first verification link from my inbox “Please click here”.

The system accepted it.

Then I completed the registration form.

5. The Result

🚨 The account was created using:

[email protected]

❌ But that email was never verified. The verification link was rather sent to my inbox instead of the victim.

💥 Why This Is a Problem

This vulnerability allows:

• Creating accounts with emails you don’t own.
• Impersonation risks.
• Blocking legitimate users from registering.
• Breaking trust in email-based identity systems.

In simple terms:

The application verifies the wrong email address.

🧨 Exploitation Scenario

An attacker could:

1. Register with their own email.
2. Change it to a target’s email (e.g., [email protected]).
3. Verify using their own inbox.
4. Create an account tied to the target’s email.

This could be abused for:

• Impersonation.
• Social engineering.
• Abuse of business workflows.

🧩 Root Cause

The issue exists because:

• The system does not invalidate the original verification token.
• No new token is generated for the updated email.
• The backend trusts the old verification session.

🛠️ How It Should Work

A secure implementation should:

• Invalidate old tokens when email changes.
• Generate a new verification link.
• Send it only to the new email address.
• Block progress until the new email is verified.

📌 Impact Assessment

Although the application required admin approval, the vulnerability still:

• Breaks email ownership validation.
• Allows identity misuse.
• Weakens authentication integrity.

🏁 Responsible Disclosure

The issue was responsibly reported and accepted by the security team.

This highlights how even small logic flaws in authentication flows can have real-world impact.

🧠 Key Takeaways

• Always test edge cases (like “change email”).
• Don’t trust frontend messages blindly.
• Business logic bugs are often hidden in plain sight.
• Email verification ≠ secure if logic is flawed.

✍️ Final Thoughts

This bug is a great reminder:

Security isn’t just about encryption or firewalls —
it’s about getting the logic right.

If you’re into bug bounty hunting, keep digging into:

• Registration flows.
• Password resets.
• Email verification systems.

That’s where some of the simple vulnerabilities hide.

🔗 Connect

If you enjoyed this write-up, feel free to follow for more real-world bug bounty discoveries.
https://x.com/ethical_h4ck3r_
More to come… 🌇