☕ My First Critical Bug: Account Takeover with Just One Tiny Letter

Bug bounty is wild. Sometimes you fuzz for hours and find nothing. Other times, one tiny character can open the door to a Critical Account Takeover.

This is the story of how I landed my first ever Critical bug with nothing but a Unicode trick.

🕵️ The Setup

I was testing the usual account flows: Register → Logout → Try again, Forgot password flow. Nothing special. Just routine testing.

Then I thought: “What if I mess with the email?”

🎭 Enter Unicode Homoglyphs

Step 1️⃣ — I registered an account with:

mytest@gmail.com.burp-collaborator.com

Step 2️⃣ — I logged out and tried signing up again. But this time, I intercepted the request in Burp and replaced the letter a with a Unicode homoglyph à:

mytest@gmàil.com.burp-collaborator.com

The server’s response? ❌ “Email already exists.” That was the first big red flag.

🔑 Forgot Password Flow Gone Wrong

Next, I moved to the Forgot Password feature.

• Entered the homoglyph email (gmàil.com).
• Intercepted the request and sent it.
• The system happily sent the password reset code… but it went to the original email (gmail.com).
• Since I had it pointing to Burp Collaborator, I caught the OTP.

With that OTP, I reset the password and logged in to the account. ✅ Result: Full Account Takeover.

☠️ Impact

This bug let me:

• Reset passwords of existing users.
• Take over their accounts completely.
• Access private data.
• Impersonate them without their knowledge.

🧑‍💻 Root Cause

The application didn’t normalize email inputs properly.

• a and à were treated inconsistently between registration and password reset flows.
• That mismatch allowed attackers to trick the system into sending OTPs to the wrong place.

🛠️ Suggested Fix

• Normalize/strip Unicode homoglyphs in emails.
• Enforce RFC-compliant validation for email addresses.
• Apply consistent validation across signup, login, and password reset endpoints.

— AIwolfie