Hey folks, welcome back to my "finding bugs without tools" series. This time, I stumbled on a super simple (but impactful) that led to a complete account lockout for victims that came from nothing more than exploiting a simple inconsistency in how a system handled user identity.

🔎 The Setup

My target was a website with a learning platform. The structure was common:

Main Site (target.com): Featured a sign-up form asking for:

• Username
• Name
• Email
• Password

Learning Subdomain (course.target.com): This subdomain had its own, simpler sign-up process, asking for just:

• Email
• Password

Everything seemed normal at first glance. The main site login used email/Username and password, which worked perfectly.

The Red Flag

The first clue emerged after signing up on the course.target.com subdomain. The confirmation email arrived with a greeting like:

"Hi **jinx@mail.com**, welcome to our courses!"

This was interesting. The system used my email address as my username for the course platform. This is a common practice to simplify things, but it planted a crucial idea in my head.

To confirm, I looked at the page source code after logging in. Sure enough, I found a field like:

Assumption solidified: On the course subdomain, email == username.

Here's where the logic diverged. The login form for course.target.com didn't ask for an email. It asked for:

• Username
• Password

Not Email and Password. This is the key inconsistency. The system created an account using an Email as the Username, but the login form labeled the field Username, not Email.

This created a potential for confusion, but I was about to turn that confusion into a vulnerability.

🧪 The Exploit

Here's where it got interesting. Back on the main target site, I created a new account like this:

Here was my plan:

1. On the main site (target.com), I signed up for a new account.
2. For the Username field, I entered jinx@mail.com
3. For the Email field, I entered myemail@gmail.com (my own personal email).

The sign-up was successful! The main site now had an account where:

• Username: jinx@mail.com
• Email: myemail@gmail.com

The Trigger: Complete and Total Lockout

Now for the exploit. A victim, trying to access their courses, goes to course.target.com. They see the login form asking for Username and Password. Naturally, they enter their credentials:

• Username: jinx@gmail.com
• Password: TheirPassword

What happens? 👉 Nothing. The login just hangs, times out, or fails without any clear message.

The victim, frustrated, clicks "Forgot Password." The system happily sends a reset link to jinx@mail.com. They reset their password, no problem.

But when they try to log in again… ❌ nope. It still doesn't work.

They're stuck in a complete lockout loop — even after changing their password, the account is unreachable.

Why did this happen? As far as I understand, the logical flaw was that when I created a new account on the main Target app, the database ended up having two entries with the same username (jinx@mail.com). This is a problem, but I was still able to use my account perfectly when logging in with email and password. However, logging in with username and password caused issues.

I don't know remember more about this bug. I reported it last year, and they told me they wanted my name and LinkedIn to add me to their Hall of Fame, but they never did.

✨ Final Thoughts

At the end of the day, this whole finding reminded me why I love bug hunting without tools. It's not always about fancy scanners or automated scripts — sometimes the best bugs show up when you just slow down, read carefully, and think like a regular user.

A simple mismatch between username vs. email turned into a total account lockout bug. It's the kind of thing that hides in plain sight, waiting for someone curious enough to ask, "What if I try this?"

👀 Stay tuned for more "No-Tool Bug Bounty" write-ups! Got questions? Email me: strangerwhite9@gmail.com or reach out on

Twitter: @StrangeRwhite9

by StrangeRwhite | Series: Finding Bugs Without Tool