This blog was originally published here by Omar Elmasry
While doing some hunting, I found something interesting. Out of curiosity, and mostly as a hobby, I decided to check the dark web for any leaked data related to the target. Surprisingly, I came across a dump containing around 400 leaked emails belonging to @target.com.
The target application did not seem to have proper verification during account creation, which immediately sparked an idea: what if I try to register using one of those leaked corporate emails?
I started by attempting to sign up with:
tom.compton@target.comThe application responded with a clear message: "This email is already registered and cannot be used."
At that point, I turned my attention to the Change Email functionality. When I tried updating my account’s email to the same one (tom.compton@target.com), the application returned a different message: "Email is protected."
However, I noticed something important. The response was delayed by about three seconds. That delay suggested there could be a race condition.
To test this theory, I used Burp Suite to send two requests Concurrently:
- Change account email to tom.compton@target.com
- Attempt to log in at the exact same moment
The attack worked. I successfully logged in as tom.compton@target.com.
Why is there a race condition here?
Because the app uses an assign-then-check flow: it starts the email change (assigns the new/blocked address) and only validates that change a few seconds later. That brief delay leaves the system in an inconsistent state (one changing the email, one logging in)
Assign first → delay → validate → block.
(If you log in during that delay, you win the race.)
Since I had a list of nearly 400 additional leaked internal emails, the same approach could potentially be used against all of them. This means the vulnerability could lead to a full-scale Internal Account Takeover.
To add your blog, send an email to hello@bugbountydirectory.com
