The Removed Email That Led to a $500 Account Takeover

Hey everyone! 👋

I'm back with another bug bounty write-up.

While testing a web application, I found an issue in the email management and password-reset functionality that allowed a previously removed email address to receive a valid password-reset link.

The vulnerability resulted in Account Takeover (ATO) and was rewarded with a $500 bounty. 💰

🔎 What I Found

I created an account with:

attacker@example.com

attacker@example.com

Then I added and verified:

secondary@example.com

secondary@example.com

I changed secondary@example.com to the primary email and removed:

attacker@example.com

attacker@example.com

At this point, the old email was no longer associated with the account.

However, the password-reset flow still trusted the removed email.

🧪 Steps to Reproduce

1. Create an account with attacker@example.com.
2. Add and verify secondary@example.com.
3. Change the primary email to secondary@example.com.
4. Remove attacker@example.com.
5. Go to Forgot Password.
6. Enter the current email:

secondary@example.com

secondary@example.com

1. The password-reset link is sent to:

attacker@example.com

attacker@example.com

The important part is that I didn't enter the removed email in the password-reset form.

The current email triggered the reset, but the application sent the link to the previously removed email.

🔐 Account Takeover

Since I still controlled attacker@example.com, I opened the reset link and changed the account password.

I then verified:

Old Password → Invalid login credentials
New Password → Login successful

Old Password → Invalid login credentials
New Password → Login successful

This confirmed that the reset link could actually change the account password and resulted in Account Takeover.

Attack Flow

Create Account
      ↓
Add & Verify Secondary Email
      ↓
Make Secondary Email Primary
      ↓
Remove Old Email
      ↓
Forgot Password
      ↓
Enter Current Email
      ↓
Reset Link Sent to Removed Email
      ↓
Change Password
      ↓
Account Takeover

Create Account
      ↓
Add & Verify Secondary Email
      ↓
Make Secondary Email Primary
      ↓
Remove Old Email
      ↓
Forgot Password
      ↓
Enter Current Email
      ↓
Reset Link Sent to Removed Email
      ↓
Change Password
      ↓
Account Takeover

🧠 Why This Happened

The issue appeared to be an inconsistency between email management and password recovery.

The application considered the old email removed:

attacker@example.com → Removed ❌

attacker@example.com → Removed ❌

But the password-reset functionality still treated it as a valid recovery destination:

secondary@example.com
        ↓
Password Reset
        ↓
attacker@example.com

secondary@example.com
        ↓
Password Reset
        ↓
attacker@example.com

This meant removing the email did not completely revoke its role in the recovery process.

⚠️ Impact

An attacker who still controlled a previously associated email could potentially:

• Reset the account password
• Gain unauthorized access
• Modify account information
• Potentially lock out the legitimate user

🛠️ Recommended Fix

Password-reset links should only be sent to currently authorized and verified email addresses.

The application should:

1. Remove deleted emails from password-recovery eligibility.
2. Verify the current email-to-account relationship before generating reset tokens.
3. Never use historical email addresses for password recovery.
4. Invalidate recovery tokens when an email is removed.
5. Add regression tests for email changes and removals.

Once an email is removed from an account, it should no longer be trusted for account recovery.

📝 Responsible Disclosure

I reported the issue with detailed reproduction steps, impact information, and proof-of-concept evidence.

After review, the vulnerability was rewarded with a $500 bounty. 💰

💡 Key Takeaway

This finding reminded me that removing an authentication factor from one part of an application doesn't always mean it has been revoked everywhere.

When testing account-management functionality, I also check how changes affect:

Email Management
      ↓
Email Verification
      ↓
Password Reset
      ↓
Account Recovery
      ↓
Authentication

Email Management
      ↓
Email Verification
      ↓
Password Reset
      ↓
Account Recovery
      ↓
Authentication

A small inconsistency between two workflows can sometimes lead to a serious security vulnerability.

🎯 Final Thoughts

This was a good example of how an email-management flaw can turn into an account-takeover vulnerability.

The key lesson:

If an authentication factor is removed, make sure it is revoked everywhere it can be used.

Contact :

LinkedIn: https://www.linkedin.com/in/murali-dharan-k-7a6b90259/

Thanks for reading till this point!

That's all for this blog. Hope you liked it.

…Thank You!!! 🙌